Business Analyst Community & Resources | Modern Analyst

Business Analysis in the Age of AI

Pulkit Singhal — Fri, 01 May 2026 19:24:00 GMT

Business analysis work has become faster and more efficient over the past few years. Requirements are documented more quickly, discussions are summarized sooner, and solution options are produced earlier in the delivery cycle than ever before. Yet many Agile and product teams are discovering an unexpected truth: as delivery accelerates, the importance of human judgment increases rather than diminishes.

The central question facing business analysts today is no longer whether tools and automation belong in analysis work, but where judgment must take precedence. That distinction matters because the most serious failures in delivery rarely come from obvious mistakes. They emerge from reasonable decisions that appear correct at the time and gradually move teams off course.

Where Acceleration Helps and Where It Falls Short

Modern analysis practices are excellent at speeding up work that is inherently mechanical:

Converting discussions into draft requirements
Identifying patterns across large volumes of data
Refining user story language
Summarizing customer or stakeholder feedback

When used well, this removes low‑value effort from the analyst’s workload. When relied upon uncritically, it creates the illusion of progress.

The challenge is not poor quality output. The real risk lies in outputs that are clear, structured, and confident enough to pass surface review, while subtly reinforcing incorrect assumptions. This is where judgment becomes decisive.

Judgment Gap #1: Determining Whether a Requirement Is Worth Building

Clear and complete requirements do not guarantee meaningful outcomes.

In day‑to‑day delivery, analysts encounter familiar patterns:

A requirement addresses a visible symptom rather than the underlying problem
Stakeholders agree on wording but diverge on expected results
A feature meets acceptance criteria yet produces no behavioral change

Experienced analysts pause to ask questions that artifacts alone cannot answer:

What decision or behavior is supposed to change as a result of this work?
If this is delivered perfectly and nothing improves, what are we missing?

Strong analysis is not just about expressing requirements well, but about challenging their intent.

Judgment Gap #2: Interpreting Context That Never Appears in Documentation

Business environments contain layers of context that rarely make it into requirements or datasets:

Organizational dynamics and power structures
Regulatory concerns driving risk‑averse behavior
Legacy failures that shape stakeholder trust
Competing incentives across teams

Analysts recognize these signals not because they are documented, but because they have seen the downstream effects:

Solutions that are functionally correct but poorly adopted
Processes that are bypassed in practice
Reports and dashboards that exist but are ignored

Judgment here is not guesswork. It is pattern recognition developed through exposure to real consequences.

Judgment Gap #3: Recognizing When Clarity Creates False Confidence

Early clarity is often welcomed as momentum. Detailed backlogs, well‑defined flows, and polished models can make teams feel aligned and confident.

Seasoned analysts remain cautious.

They ask whether clarity is reducing uncertainty—or simply hiding it:

Are assumptions being locked in too early?
What would invalidate this design once it is tested?
Are open questions being resolved, or quietly deferred?

Sometimes the most responsible decision is to leave things deliberately unresolved, even when tools and processes encourage premature finalization.

What This Means for Business Analysts

As delivery mechanics become faster, the value of business analysis shifts away from producing artifacts and toward exercising judgment:

Framing the right problems
Interpreting conflicting signals
Evaluating consequences under uncertainty
Challenging assumptions before they harden

These capabilities are not procedural skills. They are developed through experience, reflection, and exposure to real outcomes especially failure.

Closing Thoughts

Modern tools and practices have made business analysis more efficient, but efficiency does not replace responsibility. The most effective analysts are not those who produce the most artifacts in the shortest time. They are the ones who know when clarity is helpful, when it is premature, and when the best contribution is to pause and ask a different question altogether.

That work remains deeply human and central to successful delivery.

The Benefits of Pursuing a Career as a Business Systems Analyst

Cheri Crystal — Wed, 28 Dec 2022 10:06:00 GMT

For many people, a career in business systems analysis can be an ideal opportunity to use their skills in technology and business. Business systems analysts bring together the best of both worlds – technical know-how and business acumen – to help organizations become more efficient and effective. Here are some of the key benefits of pursuing a career as a business systems analyst.

High Salary Potential

One of the major advantages of a career in business systems analysis is the high salary potential. Business systems analysts are well-compensated for their expertise, and they often have the opportunity to advance quickly in the field. According to the Bureau of Labor Statistics, the median salary for business systems analysts in 2019 was $90,920.

Professional Growth

Business systems analysts can advance their professional growth by specializing in specific areas such as health care, finance, or retail, and by using a CV writing service UK. With this focused knowledge and experience, they can create more complex solutions for their clients and optimize their career potential.

Opportunity for Innovation

Business systems analysts have the opportunity to innovate and create solutions for their clients. By combining their business and technical skills, they can create unique solutions that can improve the efficiency of an organization. This can lead to a greater competitive advantage for the organization and increased job satisfaction for the analyst.

Interpersonal Skills

Business systems analysts also have the opportunity to develop their interpersonal skills. To be successful, they need to be able to communicate effectively with clients, colleagues, and stakeholders. They must also be able to build relationships and collaborate with others to come up with the best solutions for their clients.

Job Security

As technology continues to evolve and become more complex, the demand for business systems analysts continues to grow. This provides job security for analysts and the opportunity to work with a variety of organizations. It also allows them to stay ahead of the curve by learning new skills and keeping up with the latest trends in technology.

A career in business systems analysis offers many benefits, from high salary potential to job security and the opportunity to innovate and grow professionally. With the right skills and experience, business systems analysts can be invaluable assets to any organization.

What does it take to be the best Business Analyst?

Digvijaybook — Fri, 01 Nov 2019 04:20:00 GMT

Analytics is the future of the business industry. Businesses and organizations today run on data and its interpretation. Its correct evaluation is the fundamental key to success. And business analysts are the guides to it.

It is a very prosperous industry and has a lot of potential for talented people. To even qualify, you require more than just theoretical knowledge. There are particular business analyst skills that you are required to possess. These business analyst qualities set you apart for the rest of the crowd and make you the top asset of the organization.

Communication is the key

A part of an analyst’s job is to communicate what they have found out. They have to report regularly to the management for them to take action according to their report. It is vital that communication both written or verbal are:

Clear
Concise
Conclusive
Correct

These traits are the fundamental elements of a business analyst’s skill set. No matter how good your research is, without an understandable report to follow it up, it is all in vain.

Data Modeling and structuring

Data in its raw form is not very useful to anyone. It has to be processed and presented in a manner that anyone, even without the knowledge to understand it. A business analyst’s job is to analyze the data and structure it so that it can be easily processed further. This helps in better representation of the data making it ideal to be processed further.

Manage time, and everything will manage itself

Time is quintessential. If you are unable to manage time, then you are planning to fail. A piece of valuable information is only valuable for a period of time. If you don’t act upon it on time it will no longer be useful or will have a completely opposite result than what you had in mind. Make sure you learn how to manage time. It will not only help you as an analyst but in your life in general as well.

Theoretical knowledge and creativity

You need to know some basic knowledge or academic qualification to become an analyst. This knowledge will form the foundation of your professional career as an analyst. But what you will learn, other analysts in the industry will learn too. You will need to learn how to use your creativity and improvise. Using the knowledge and turning it into your own version. This will help you create a unique profile and creating a demand for your rare skill set.

Visual and Wireframing

A business analyst provides the basic infrastructure as to how to interface will look like. It is a part of the job description to create an outline for the organization helping them to operate within the bounds. This helps the organization to be focused and driven towards its objective, facilitating better outcomes and optimizing the efforts.

Devil is in the details

An analyst needs to be focused on the task. There is a lot of information, and your work is to sort it out and condense an ocean into a bottle. Paying attention to detail is very important. You can’t skip anything as it can be the difference between success and failure. Always pay attention to the instructions and work accordingly. Let the guidelines be the creative constraints, boundaries within which you will have to operate. This will help you narrow down your focus and keep you on track. Assisting in going through everything relevant and not skipping any details.

Judgment and decision-making skills

A basic understanding, if not higher about the functions, is a must in any profession, you learn from experience, and as you grow it will improve. But as an analyst, you need above average understanding. It is important because you have to make many decisions. Such as the relevance of data and how to proceed with processing it. Without a good understanding of the operations, you are bound to make mistakes that will surely have hazardous consequences for the management, which will rely on your judgment on the final report. Make sure you have plenty of experience working in a mock environment before applying yourself in the real market. This will help you understand the functions without severe outcomes.

Thick skin

Patients and perseverance is the motto for the analytics industry. You will have to work relentlessly to get even small outcomes. Be patient. Success is built on small victories. You will feel let down, but you will have to keep going. It is not just a mental state, but you will have to be impervious to other situations as well that may come your way. Working with data and communicating it with the management is not as straightforward as it sounds. There are many complexities, and a lot can go wrong.

Incorrect application or negligence on the part of management can cause all your hard work to go to waste. It is a very thankless job, but you will have to play the role of the unsung hero. After all the audience is more interested in what goes on the stage rather than who is running it from behind the curtains, stay positive, and keep going. One day you will prove your worth and have your reward.

Always curious

As an analyst, it is your job to be nosy. Keep asking questions. The more you ask, the more it will be clear to you what is needed off you and the better you will perform. There is no such thing as a shy analyst; there are just different job profiles. You will have to keep insisting on having more information to work with to narrow down your focus to what is the outcome should be. Not asking questions will lead to miscommunication and create problems when you submit your final reports. No one wants to redo something they have invested a lot of time into. So always think about a better outcome because, as an analyst, that is the only thing that will help you improve your productivity.

To Conclude

Analysis of business is a difficult choice. It is not as easy as it sounds. A small error can cost the organization a lot of money, and no one wants to be the cause of the loss. It is bad for your professional reputation as well as your career. Always keep in mind what is at stake and work according to instructions. Creativity is very important, but it should not enter the realm of fantasy. This does not mean you don’t try new things. You need to be a blend of bold and cautious at the same time.

For more information, please visit https://www.janbasktraining.com.

How did I achieve my CBAP?

Trividh Patel, CBAP — Sat, 09 Mar 2019 12:19:00 GMT

At first, I wanted to tell people how they should go about getting their IIBA certification. But then I thought the best way to do this is by actually telling “how did I achieve my own CBAP?” So, friends here is my story.

I started working as Business Analyst in 2002. I have used multiple elicitation techniques (such as interviewing, workshops, focus groups, etc.) and different requirements analysis techniques such as process modelling, use case modelling, user stories, prototyping, business rules analysis, non-functional requirements analysis, business case development etc. I have had good experience in business analysis projects working for clients worldwide.

By 2011, I already had about nine years of experience in business analysis when I have decided to go for my CBAP certification.

First thing I did was to check if I was eligible to apply for IIBA CBAP certification. So, I studied IIBA CBAP handbook and understood that IIBA evaluates business analysis experience in terms of 6 knowledge areas and I was supposed to have total of 7,500 hours of business analysis work experience and minimum 900 hours in at least 4 knowledge areas to apply for CBAP certification.

So, I studied IIBA BABOK guide version 2.0 and understood various business analysis tasks under each of the 6 knowledge area. This was the latest IIBA BABOK guide at that time. I started analysing my project experience from the IIBA perspective. I have listed down all the projects I have worked in my career and identified different business analysis tasks and activities I have performed and figured out number of hours I must have spent in each of those tasks and activities. I aggregated number of hours as per knowledge area and also calculated total hours of my business analysis experience.

To my surprise, I had well over 7,500 hours of business analysis experience and over 900 hours in all the 6 knowledge areas.

Next thing was to get 2 professional references and out of that one was supposed to be current contact. So, I approached my career manager and explained him benefits CBAP will bring to the organisation as well as to me. He gladly agreed to provide recommendation. Next, I approached single point of contact from one of the client organisation and he too agreed to provide me recommendations for CBAP certification. I have also contacted various colleagues from past projects and companies and got their buy-in in case IIBA would want to audit my project experience.

Next thing was to ensure I fulfil professional development in terms of contact hours. I understood from CBAP handbook that training can be in any area directly related to business analysis. As I already have had enough business analysis work experience, I thought of attending full time lean six sigma certification training. Please note that the training provider was NOT an Endorsed Education Provider or an EEP and still it was accepted by IIBA. Many people don’t know that IIBA does not mandate training provider to be an EEP but mandates training to be relevant to the business analysis and must be instructor led classroom or virtual live (for CCBA and CBAP application). However, for ECBA application training can be online without instructor.

After attending training, I have submitted online application on the IIBA website. I have provided information such as my education and work history details such as Project Name, Start and End dates, project Description, Total BA hours, Project contact details and various BA activities performed. I have also provided professional training details and two professional references.

After submitting application, I have paid application fee online. Within a week I received confirmation email from IIBA that my application was approved and I am supposed to pass the certification exam in 1 year from the date of approval email.

So I started preparing on my own for CBAP certification. I have studied IIBA BABOK guide at least 4 times. I have correlated concepts in the IIBA BABOK guide to my actual project experience. I have also figured out ways to remember concepts such as involvement of stakeholders and use of techniques in various business analysis tasks. It took me over 6 months to prepare.

Once I was confident I have identified nearest venue available for taking the exam and paid the exam fee.

I have registered and scheduled my CBAP exam for 15-March, 2012.

The exam venue was almost at one and half hour drive from my home and this time was subject to traffic conditions. So, I tried searching for a hotel near exam venue but there was no hotel nearby. So, I have approached a friend whose house was fortunately nearby the exam venue and he gladly agreed to let me stay overnight.

So, I stayed at my friend’s place and next day I reached venue on time. I showed my exam conformation emails and proofs of identification to the exam supervisor. I used provided username and password to logon the exam application.

I started attempting CBAP exam but soon I have started experiencing noise from other desks. I requested people and also to exam supervisor but it was of no use. Just then I remembered that I have ear plugs. Use of ear plug really helped to significantly reduce the noise and let me attempt exam without much disturbance.

I again started attempting questions. I have flagged certain questions for which I was not very confident. After attempting all the questions, I revisited flagged questions and took calculated risks and tried to figure out the best possible answer. After doing this, I still had about 20 minutes so I quickly browsed through all the questions and answers. I found couple of mistakes made while selecting my choice of answers. I made corrections and submitted my answers for evaluation.

Within just 30 seconds, I got message on my screen that I have successfully passed my CBAP exam!

I got email from IIBA confirming the same. I was also informed that my name will be included in list of CBAP recipient on the iiba website and also that I shall receive my certification kit in another 2 months time. I was also told that from now on I was licensed to use CBAP in my name and in my communication.

Well, that was my story and I am sure you too would have yours one day. All the Best!

About Author - Trividh Patel, CBAP

Trividh Patel has over 17 years of experience in Business Analysis and Consulting in IT services industry.

He has worked for leading IT Services companies as Business Architect, Lead/ Sr. Business Analyst, and as IT Project Manager. He has executed several business analysis projects for reputed organisations from USA, UK, Europe, Middle East, Japan and India. He has good track record of leading team of Business Analysts to deliver business analysis projects.

Trividh Patel has done MBA in Systems and Bachelor of Engineering from University of Mumbai (India) and is Certified Business Analysis Professional (CBAP) by International Institute of Business Analysis (IIBA), Canada since March 2012. He is also Certified Six Sigma Black Belt (CSSBB).

Trividh Patel can be reached on LinkedIn: http://www.linkedin.com/in/trividhpatel-cbap

Business Analysis Career Path

Hitendra 01 — Thu, 22 Mar 2018 02:23:00 GMT

Most IT jobs have a clear, specific job description and career path. However, the business analyst career path tends to vary, as do the descriptions from job to job. The business analyst career path is best. Because, “There are career tracks that zigzag back and forth between IT and business. Someone might start as a business analyst, and then move into a project management job, then an IT management path, and then go back to an innovation path ... then to process management, then move up a rung to process leadership or process ownership, and then go back over to management as manager of an IT line of business."

Today’s Business Analyst

The 21st century business analyst’s world is multifaceted. As a mediator, moderator, connector and ambassador, the business analyst must bring the business needs together with IT resources. Successful business analysts tend to be clear communicators, smooth facilitators, precise analyzers and team players. Plus, the ideal analyst has the versatility of various business functions, such as operations, finance, engineering, technology or architecture. Business analyst role is fuzzy at many companies. These jobs usually describe what a BA does by telling people I am a bridge between business systems from the end user to functional implementation of technical solutions. But when you tell somebody that they look at you like ’OK, what do you really do?’"

What Does a Business Analyst Do?

As you explore the business analyst career path, you’ll need to clear up the confusion and learn about the many hats business analysts wear. From being a good communicator and data analyzer to possessing project management and technical skills, business analysts regularly use a variety of techniques. They are the bridge that fills in the gap between each department throughout every step of development. Modern Analyst identifies several characteristics that make up the role of a business analyst as follows:

The analyst works with the business to identify opportunities for improvement in business operations and processes
The analyst is involved in the design or modification of business systems or IT systems
The analyst interacts with the business stakeholders and subject matter experts in order to understand their problems and needs
The analyst gathers, documents, and analyzes business needs and requirements
The analyst solves business problems and, as needed, designs technical solutions
The analyst documents the functional and, sometimes, technical design of the system
The analyst interacts with system architects and developers to ensure the system is properly implemented
The analyst may help test the system and create system documentation and user manuals

Starting Your Career as a Business Analyst

Beginning business analysts need to have either a strong business background or extensive IT knowledge. With that, you can start to work as a business analyst with job responsibilities that include collecting, analyzing, communicating and documenting requirements, user-testing and so on. Entry-level jobs may include industry/domain expert, developer, and/or quality assurance. Within a few years you could choose to become a Subject Matter Expert (SME). This is the time to delve into the areas that interest you most and develop those areas that can help you progress into higher management positions.

Moving Up the Ladder

Once you have several years of experience in the industry, you will reach a pivotal turning point where you can choose the next step in your business analyst career. After three to five years, you can be positioned to move up into roles such as IT business analyst, senior/lead business analyst or product manager. The more experience you have as a business analyst, the more likely you are to be assigned larger and/or more complex projects. After eight to 10 years in various business analysis positions, you can advance to chief technology officer or work as a consultant. You can take the business analyst career path as far as you would like, progressing through management levels as far as your expertise, talents and desires take you.

How Much Do Business Analysts Make?

Depending upon which business analyst career path you choose, you’re certain to benefit from a highly rewarding and lucrative career. To give you an idea of how profitable this field can be, take a look at these job titles and average salaries, based on U.S. Bureau of Labor Statistics, for a variety of business analyst jobs:

Job Title	Average Annual Salary
Information Security Analyst	$92,600
Computer Systems Analyst	87,220
Management Analyst	$81,330
Financial Analyst	$81,760
Budget Analyst	$73,840

8 Ways to Be a Badass Business Analyst Employee

Paul Crosby — Wed, 07 Sep 2016 14:23:00 GMT

Being a badass isn’t about intimidation or trying to be something you simply are not. It’s about knowing who you are and using your strengths to drive forward. So let’s look at a few of the ways to be a badass in business:

1. Passion for Your Craft Is a Powerful and Infectious Energy

Showing passion for your work in always willing to learn more and explore new ideas in your profession shows you are a badass. A badass isn’t afraid to learn something new about their craft. Always be willing to step up to the plate and show what they are good at performing. Sitting back and doing just the expected is not the badass way. If you are amazing at drawing diagrams, then use them frequently in your work.

A few years ago I was managing several projects. Things were not going all that well on these projects, and I knew something needed to be done to get them on track. Holding up the schedule and pointing at it wasn’t solving the problems we were facing. I decided to explore different approaches and ideas by contacting others outside the company for their advice and doing a little reading up on handling scope problems in projects. I learned a lot of scope management techniques as a result of that exercise and was able to apply them to my project. My boss at the time noticed I went out of my way to figure out new approaches, and I was fearless in learning new techniques about my craft. By learning and stepping out to explore new ideas I was able to move the project forward and save the project from failure.

2. Keep Positive

Nobody likes a negative person constantly interrupting, jumping to conclusions and always complaining. Keep a “we can do this” mentality even in the toughest of times. The measure of a badass is in being able to be calm, think clearly and project positive possibilities. When the whole world is crashing down, don’t be the one saying “Well that figures.” Instead be the one saying “This isn’t the greatest situation, but we have some great opportunities here to make positive changes.” See the good in situations where others cannot. Be the person that says “I’ve got a few ideas that might help in this situation, and I would like to bounce a few of them off of you.”

One of the toughest projects I faced was working with remarkable requirements, but a development staff that either didn’t want to or just could not fulfill those requirements with the current system in place. The team quickly got very negative at all the challenges that we were having in development. Everyone’s attitude soured and nothing was getting accomplished. The project was on its way to failure. So I threw a pizza party. My entire team thought I lost my marbles, and it was time to call the men in white coats to pick me up. Pizza does wonders for putting a team in a better mood. I told the team I understood the situation was bad and acknowledged that the company wouldn't accomplish anything without their skill sets. I purposefully turned the conversation from a negative (What is going wrong?) and made it positive (What ideas do you have to make it better?).

This was no easy task. I had to work very hard to move everyone’s attitude toward the positive after months of being in the negative. I was direct in telling them “Nobody wants to work on a negative team – it sucks. What can we do right now to make this team more fun and productive?”. After that hurdle had been cleared, it got easier to involve everyone in making team changes and design changes to the project. I kept telling myself that no matter what happens I will remain positive. The team’s attitude evolved over time. Many team members and company leaders repeatedly said that they could always count on me for being positive and finding solutions to problems.

3. Know Your Craft and Tools

A badass doesn’t just stop learning the basics of their craft or tools. They are constantly expanding their toolset and keep current about their craft. It’s too easy to get comfortable and begin to feel there is nothing more to learn. A badass grabs any opportunity to learn new things.

In my past life, I was at a company where I was pigeon-holed. I did such a good job at data warehousing and reporting that no one wanted to let me try anything new or different. Damn, I was bored out of my mind because every day was the same thing over and over. Sure I was learning new things about data warehousing and reporting, but I never stepped out of that area into other areas. So I forced the issue a bit and shoehorned my way into a call center application. It made sense for me to pursue it because that new system would be feeding the data warehouse. I went a little further than just worrying about data and started moving into user interface design and workflow for the new call center application. It was a great experience to use the knowledge I had in data warehousing and reporting to build better user interfaces and business processes. After the project had been finished, I was seen as being useful in business process as well as data warehousing. The door opened, and I got the chance to work on a whole new set of projects. Don’t be afraid to step out of bounds – you just might be valued for it.

4. Make Life Better for Others

A badass knows that improving the lives of their team members by continuously being focused on improving the way things are done is important. Being innovative to solve problems the team is experiencing in the day to day operations is just as important as solving project problems. Process improvement is powerful. A badass understands it’s not about single glory but helping others to achieve great success.

You always hear “It’s not my job” especially in large companies with well-defined roles. A badass looks for ways to improve the working conditions and tasks their team performs. It can be a simple as creating a library of past project documents that can be reused or finding a new way to perform time reporting that is easier. Whatever it is, a badass is looking for ways to improve processes at every moment and isn’t afraid to suggest well thought out changes.

5. Know Thyself Well

Know thy strengths and know thy weaknesses. A badass is aware of their strengths, and they know their weaknesses and limits. In today’s corporate culture, we focus on weakness. By focusing entirely on weaknesses, performance appraisals have become more like firing squads. A badass knows to play to their strengths and to engage others to help them out with their weaknesses.

There are certain things I have discovered I’m genuinely bad at. Anything that involves molding clay into an object is bound for disaster. Both of my skiing trips ended in an uncomfortable tree hugging. In business I know I’m a driver – be quick, be bright and be gone. It wasn’t until half way through my career that I realized how that impacts others who are not drivers. By understanding how I lead and act, I was able to soften my approach and be more collaborative with others. My driver mentality is a strength that others recognize. I can snow plow through massive amounts of data to give clear direction. I communicate quickly and concisely on projects.

Play to your strengths at all times. If you know you are weak in an area, then go out and find someone who is strong in that area to balance you out. If you get the chance to put teams together, look at each others strengths and weakness to balance them all out. Forget about finding that perfect all around team member without weaknesses. They don’t exist.

6. Don’t Always Say What They Want to Hear

Being a butt kisser or yes man is not the path of a badass. If you are always saying what others want to hear from you, they will never fully trust you because they can’t tell if that’s what you honestly believe or if you are just being a parrot and repeating everything back to them. A badass understands that conflict is part of life, and sometimes you are going to have to say what doesn’t want to be heard.

The trick here is saying it without being annoying or a jerk. If there is an elephant in the room, then say there is an elephant in the room. A badass knows that hiding the obvious doesn’t make it go away but rather gives it greater power. Address it quickly and directly. Forcing the issue is a one-way ticket out the door. Follow the “Toot, Toot and Salute” rule. Bring it up once and if there is no response or disagreement then re-group your thoughts. Bring it up again and if there is still no response or disagreement, then accept it and move forward.

7. Ask Questions, Challenge and Dig Deep

No one likes to be challenged. It puts them on the defensive right away. A badass understands that challenging an idea is an art form and that challenging helps bring deeper understanding and meaning. A badass knows that without asking questions and digging deep, the entire problem cannot be understood fully.

Nobody likes to feel they are being interrogated. Be fearless but considerate in digging deep. Verify your thinking and dig deeper with “Help me understand” questions. Share what you have learned to validate it. Be appreciative of the different perspectives and gather them all up to see the greater picture more clearly. The most significant problems I created for myself was making assumptions and never validating those assumptions. You may not be able to validate or challenge at that specific moment. Write it down, reflect on it and determine if you need to challenge it. Challenge appropriately and thoughtfully. Step back and schedule a challenge at a later time.

8. Lead Even When Your Job Title Doesn’t Say Leader

A badass leads even when it isn’t in their title or role. They had the initiative and don’t shy away from leading in their craft. They don’t wait for someone else to schedule the requirements meetings, they step up to the plate and schedule them.

In the many times, I have played the role of the business analyst I’ve stepped outside my role a bit. I’m probably more comfortable with that then other business analysts in that I have been a project manager. My favorite is when I’m told how long it will take to gather requirements. You know those meetings were without being consulted the project manager has decided how long you as the business analyst will take to gather requirements and complete the design. When I’m in the business analyst role, I often will put together a requirements work plan outlining the steps that will be taken to elicit requirements and build the design. I review it with my stakeholders, project team and sponsors. This runs face first into the project managers desire to create and control the schedule. By gaining common agreement on tasks for the requirements and design process, the schedule can be more reasonably created which in turn helps the project keep to its timeline and budget. Is there a negotiation? Oh yeah – there will be lots of negotiation with the project manager, sponsors, and stakeholders on what will be done and what won’t be done. Step up to leading the task and schedule you will be expected to adhere to for the project.

For more good stuff on business analysis and leadership, check out the blog at Bob the BA.

How A Dentist Appointment Made Me A Better BA

rlogan1301 — Tue, 17 May 2016 16:36:00 GMT

My youngest daughter was scheduled for her first dentist appointment. She couldn’t contain her excitement. She had her stuffed dog, dentist-visiting attire and bright, sparkling smile ready for the event. She was ready to go. Little did I realize that not only would my daughter come away with a clean-bill of dental health, but that I would come away a better business analyst as a result.

1. No pre-conceived notion – My daughter was excited with no apprehensions and no self-fulfilling prophecies to sway her. She had no idea what it was going to be like nor did she hold any opinions on the matter. She just knew that her older brother and sister went regularly and now it was her turn as a ‘big girl’ to go to the dentist! Kids are not born with pre-conceived views of the world. Most of what they experience is a surprise (pleasant or unpleasant) and an adventure. As adults, we have lived through many different experiences and as such, some of us dread going to the dentist. As a business analyst, we deal with pre-conceived notions on projects all of the time. End users, sponsors, subject matters experts all have some sort of view or opinion on the purpose (goal) of the project. Some views are positive (end users are really needing this enhancement) where other users are skeptical or out-right negative/cynical about the purpose. As a business analyst having a view or opinion of the project is ok, but I find one is far better served to suspend all judgement…the success of the project increases when the business analyst leaves his\her views at the door.

2. Curiosity - One of the results of my daughter’s experience was a ton of questions directed at me. “Why do you have to sit in a long chair?”, “Why does the doctor wear a mask?”, “Why do I need my teeth cleaned?”, “why?”, “why?”. Some of her questions may have been her wondering why I would do such a thing as to send her to the dentist, but I think most of them were simply driven by her basic and innate curiosity. In my opinion, curiosity is the foundation of a business analyst. This curiosity is the driver towards discovering root cause within a project and ultimately providing that “what is the problem we are trying to solve”…the real ‘a-ha’ moment. I have been on projects where, as a result of the “whys”, it was discovered that a technical solution wasn’t even needed and that a change in the business process, communication method or organizational structure would better solve the problem.

3. A constructive Lack of Inhibitions can go a long way…not being afraid to ask questions and not being reticent about not knowing the answers – after answering the litany of “why” questions thrown at me I came to realize that she was very courageous to even ask these questions. She wasn’t afraid that her questions may change my perception of her and she wasn’t afraid to challenge her father or the situation. Having the courage to ask “dumb” questions (even after being told there are no dumb questions) drives the conversation forward. It also encourages others to ask “dumb” questions because then, the underlying foundation for “if he can ask that then I can ask this” leads to better discovery and understanding.

4. Celebrate a Milestone - after her appointment what is a father to do? You guessed it...take her to get ice cream. Am I going to win father of the year? Probably not, but I wanted her to celebrate her first dentist appointment and her conquering something that was unknown and, possibly, scary with a positive “end note”. Participating in a requirement(s) sessions can be an unknown adventure that is both challenging and rewarding. Recognizing the successful completion of requirements for a project is a big deal and, as a business analyst, you should bring to light the major accomplishment (milestone) that it is. Do you need balloons and catered hors d’oeuvres? No, but explaining how the completion of this milestone will foundationally impact the rest of the project goes a long way.

I didn’t expect an innocent visit to the dentist office with my youngest daughter could correlate so closely with my daily challenges as a business analyst and provide me such insight into my profession, yet I remain grateful for the education and perspective I gained. I wonder what I shall gain in the years to come from similar experiences? I’m hoping I find such introspection and edification when the time comes for her to venture into orthodontia for braces.

Randall Logan is the President of PushPull, LLC (www.pushpulltech.com) a management consulting firm in Indianapolis. Randy has over 18yrs experience as a business analyst, project management, process analyst and consulting within the retail, manufacturing, finance, high-tech industries and can be reached at randall@pushpulltech.com

Things to know before you start your BA career

Bharat Mamtani — Mon, 25 Apr 2016 02:18:00 GMT

Now when I am already a successful BA since many years, I would like to share few moments with everyone.

During my first months as a business analyst, life was filled with a sort of inner turmoil. Even though I had books on how to write requirements documents, had received individual mentoring on putting together use cases, and had a trusted set of templates to follow, there was something uncertain about how the business analysis process would actually unfold.

I found myself making a lot of mistaken assumptions about what to expect, having those assumptions prove to be unfounded, and then needing to find ways to adjust and course correct. Looking back, there is nothing unexpected about my experiences, except that they were unexpected to me at the time.

Knowing that many of you are just getting started, today I am sharing 4 of the things I wish someone had told me when I was just starting out in my business analysis career.

Need to set expectations early and often, and then again and again and again…

As a business analyst, it’s not uncommon to receive too many assignments, tasks that are outside your bailiwick, or unreasonable deadlines. I was surprised to find myself constantly explaining what I was doing, why it was taking so long, and what could be expected of me over the coming weeks, even though I didn’t always know what the next week would look like!

I also found that deadlines would seem reasonable but became overly optimistic when I didn’t hear back from stakeholders in a timely manner, couldn’t get time on the calendar with a critical stakeholder for weeks at a time, or encountered unexpected issues.

I learned to continually clarify my role, communicate about what would be done when, and seek feedback to be sure I was meeting expectations.

Getting information could be a little painful

Early on in my career, I naively expected unlimited access to stakeholders and their unhindered involvement in and passion about my projects.

The reality was much different. My stakeholders had multiple projects, conflicting priorities, and too much to do. Even when my project was important to them, it could still be difficult to get the information I needed in a timely manner.

Over my career, I learned to be a bit of a squeaky wheel – a very polite, diplomatic, and conscientious one – but squeaky nonetheless. My projects started to move more smoothly and I met my deadlines with less angst.

Although being the requirements author, you aren’t the requirements owner.

I love to write and I love to write requirements. But I could get so caught up in writing and documenting and modeling that I would take on more ownership than was prudent. This would lead to a lack of buy-in from critical stakeholders, which could translate to unexpected changes late in the project.

The reality is that we absolutely need stakeholders to take ownership of the content going into the requirements document, even as we author that document on their behalf. And yes, they are likely to resist reading, reviewing, and providing feedback on requirements.

I learned that providing early, incomplete drafts that were clearly imperfect would help stakeholders see that they could add a lot of information and clarity into the requirements. I also learned to be very specific about the status of any given deliverable when sending it out, and equally specific about what I was asking of my stakeholders of this document at this time.

Dealing with issues professionally would take a new kind of finesse

I’ve always been a proactive person and a bit of a whistle-blower. When a new issue surfaced, I would signal the alarm, rally the troops, and facilitate a problem solving meeting.

However, discovering requirements is a gradual process of gaining clarity and minimizing ambiguity. At a certain point in time, every requirement was once an issue. Business analysis surfaces so many issues that you can’t possibly resolve all of them immediately.

With experience, I learned to blow the whistle more softly, keeping everyone informed about what was surfacing, but not unnecessarily alarmed. To keep the requirements process moving forward, I also learned to take ownership of the issues that surfaced inside of the requirements, and make more decisions about how to resolve issues and which options to choose or recommend.

Now that you know what to expect

Now that you know what to expect, perhaps you won’t be as caught off-guard as I was during your first days as a business analyst!

Happy Analysis !!!

Research: Roles and background before becoming a Business Analyst

Trividh Patel, CBAP — Mon, 11 Jan 2016 02:28:00 GMT

I am pleased to share the analysis of a Qualitative Survey to understand the backgrounds of Business Analysts (BAs) and the roles they have held prior to becoming BAs. This survey was conducted as an informal poll on LinkedIn. The numbers of participants are over 250 and hence are statistically significant to infer.

Inferences

Developers/ Programmers are the highest to become BAs (most of them after becoming a Tester, QA Analyst, Systems Analyst, or Project Manager).
Business side Subject Matter Experts (SMEs, including end-users) are the 2^nd highest to become BAs (some of them after becoming Tester or Project Manager).
Project Managers and Systems Analysts are the 3^rd highest to become BAs.
MBA and Bachelors degree in Information Systems has helped to directly become a BA.
People with other roles/background that have become BAs include
- Testers and QA Analysts
- Application Support and Customer Support
- Sales, Marketing and Relationship Managers
- Data Analyst
- Technical Writers (including those working on proposals)
- Technical SMEs (Implementation/ Configuration Analysts)
- Project Coordinators

Conclusion

People from diverse backgrounds (technical, business, support etc) and roles have become BAs but there is no one particular path that can suit all, hence your own efforts and hard work will get you where you want.

About Author

Trividh Patel, CBAP® has well over a decade of experience in an IT services industry, in various functions such as Business Analysis, Business Technology Services, Presales, and Project Management, primarily in Banking, Financial Services, and Insurance domain.

Trividh has done his MBA from JBIMS, University of Mumbai, and Bachelor of Engineering from VJTI, University of Mumbai.

Trividh Patel, CBAP® provides specialized Business Analysis Trainings, such as

1. Fundamentals of Business Analysis
2. Mastering Use Case Modelling
3. CBAP® / CCBA® Certification Prep Course

Trividh Patel can be reached on -
LinkedIn: http://www.linkedin.com/in/trividhpatel

From Developer in India to Business Analyst Abroad

Adrian M. — Wed, 28 Jan 2015 12:19:00 GMT

Business Systems Analyst as a Career Option

If you are an IT professional in India, thinking of working abroad, you might want to consider a business/systems analyst position.

Why?

It’s a position in high demand with high earning potential and which can serve as a great foundation for moving up the corporate ladder into management or business operations.

In on of Money Magazine’s Best Jobs in America list, the Computer/IT Analyst career was ranked 7th, out of 50 best jobs, with a 10-year job growth of 36.10%.

In one of their “Best Careers” report, US News and World Report lists 25 professions that will continue to grow in demand. With the advent of outsourcing, it is not surprising that the software engineer or web developer professions are NOT on the list - however systems analyst is.

All industrialized nations are heavily outsourcing the programming of software to other parts of the globe such as Russia, India, China, Eastern Europe, and South America.

While there’s still demand for developers, of course, the information economy has created an ever increasing need for business analysts and systems analysts.

As a matter of fact, the very outsourcing of programming jobs has caused a spike in the demand for business systems analysts. The increase distance between the business stakeholder and the programmer has created an increasing need for higher quality and more precise analysis artifacts such as requirement documents and functional specifications.

In addition – in a more an more competitive economic landscape business organizations continue to strive to improve their business processes and reduce costs. Business analysts are at the center of most of these initiatives.

So are you ready to make the move?

Before you take the plunge, you should do a quick self assessment to determine if the business analyst role might be a good fit. You’re probably a good candidate if:

you don’t want to spend the rest of your career in front of a monitor debugging code,
you love to talk to people and socialize,
you not only love to talk to people but you are actually a good communicator,
you are good at organizing information in a structured and concise manner for others to consume,
you want to, and are able to, grasp the big picture,
you are fascinated by how companies actually make money, about the business systems and processes in place.

OK… so if you still think that business systems analysis is for you, then let’s take a quick look at what you need to begin a career as a business/systems analyst.

For starters, if you are a developer you already have a great advantage:

you think in a structured manner,
technology is not magic but something you actually understand,
you are most likely used to working in a variety of industries,
lack of detailed business knowledge causes you to ask very relevant “why” questions,
you know how to talk to the technical side, and
you probably have already been reviewing artifacts created by the business analysts.

So what’s next?

If I were forced to pick the top two skills or abilities that a BSA must have I will always pick strong communication skills and analytical (structured) thinking.

Communication Skills

The first thing you need to focus on is communication skills. No matter how good your communication skills are you can always learn more. This is a must have skill for the business systems analyst.

If you are assessing your abilities and trying to figure out which aspect of communication to work on next, here are some areas to consider (pick the one in which you are the weakest and run with it):

ability to verbally communicate your thoughts and ideas to others and make yourself understood,
ability to understand others and to ask relevant questions which cause the other party to give you the information you are looking for,
ability to write clearly and in a concise manner (when creating analysis artifacts - less is more)

Analytical/Structured Thinking Skills

The next thing is structured (logical) thinking… this is one of those aptitudes which, at some level, I almost want to categorize as “you either have it or you don’t.” However I haven’t yet found conclusive evidence to support my claims – not yet.

So for now, work on improving your analytical and problem solving skills as without them, you will fail as a business systems analyst or, at best, you will be a technical writer with a BA title.

If you are assessing your skills in this area you might want to consider focusing on the following:

techniques which help you organize your thoughts or the facts about a given problem,
methods of making a problem more manageable such as: divide and conquer, abstraction, problem solving patterns,
formal reasoning skills such as: propositional reasoning, identifying and controlling variables, suppositional reasoning, etc.

For more details check out Mind Tools, a good resources of ideas and techniques to improve your analytical and structured thinking skills.

Keep on Learning

While I would argue that a software developer/programmer with strong communication skills and great analytical/structured thinking can easily land a business/systems analyst job, there numerous other abilities and skills you should develop if you plan to make business analysis a long-term career.

Here are some things to think about:

Requirement Elicitation Methods – as a business analyst you will be eliciting requirements from the business stakeholders therefore it will serve you well to become familiar with various requirement gathering techniques such as: end-user interviews, job shadowing, questionnaires, etc.
Vertical domain knowledge – if you are interested in a given industry (ex: mortgage banking, pharmaceutical, etc.) or if you already have previous experience in a given industry you should consider beginning your business analyst career in that industry. Of course – learn as much as you can as the more you know about a given business domain the more effective you will be as an analyst.
Knowledge popular modeling techniques (activity diagram, sequence diagram, data flow diagram, workflow/process flow diagram, etc.)

Adrian

Employers Should Do More to Train Business Analysts

Adrian M. — Wed, 17 Dec 2014 12:45:00 GMT

While the Business Systems Analysis line of work is just beginning to be recognized as a profession of its own, the shortage of business analysts and systems analysts continues to get worse.

And the shortage is global!

Would you believe that India is having a shortage of qualified IT professionals? Well, you better believe it!

A while back, Mary Hayes posted a great piece on the shortage of IT talent in India. She stated that “the IT talent shortage there has hit a tipping point.” Four companies alone, Accenture, IBM, Infosys, and Tata were looking to hire additional 35,000 tech workers in India in just the first 6 months.

A separate article, discussing the business analyst shortage in Australia, states that there are simply not enough people to fill the open business analyst positions.

In the USA, the shortage of qualified analysts is just as bad. Just take a look at the sheer number of job postings for business analysts and systems analysts on the major job boards (Dice.com, Monster.com, etc.).

Should universities crank out more graduates?

The reality is that universities can only teach so many technical skills. And most of them do not teach critical competencies need by analysts such as big picture systems thinking, soft skills, problem solving, and requirements elicitation.

I graduated with a degree in Computer Science from UCLA, a school well known for its engineering degrees. However, I had only one course which taught me skills which I had later used as systems analyst. And that course was taught by an outsider, a consultant from RAND corporation. He split the class into small teams and told us to come up with a software product, pitch the idea in front of the entire class, document the requirements, design the system, build it and try to sell it.

Wow! That was cool!

Unfortunately, that was the only such course that UCLA offered and it was just a pilot course which was available for only two quarters (I hope they brought it back).

Most college professors do not have industry experience – they have rarely been involved in developing real systems that customers pay money for.

I am not saying that a technical degree is of no value – I’m just saying that it’s not enough.

So what is the answer?

I believe that employers should do more – much more - to address this problem. Large companies should create in-house training programs to teach real-world skills to future business and systems analysts through a variety of methods: seminars, mentoring, real-life projects, etc.

Many recent tech graduates would be willing to commit to a 2-3 year stay with a major company if they are promised a well-thought out training plan and the prospect that at the end of the training period they would have gained the competencies needed to succeed in the real world as professional business analysts or systems analysts.

Some companies are getting the message!

Infosys, started a program called Campus Connect to polish up the basics and teach vital skills to engineering/computer science students in colleges across India. Yes, they have a great incentive: about 24,000 tech job openings per year.

Kudos to Infosys!!! Everybody benefits!

The Campus Connect program teaches students critical skills such as:
- Systems analysis
- Hardware architecture
- Data storage
- Soft skills
- Problem solving,
- Etc.

Do you think the employers should do more to reverse the shortage trend?

Would love to hear your thoughts!

Adrian

BA: If You Want to Succeed, You've Got to Read!

Adrian M. — Sun, 16 Nov 2014 22:15:00 GMT

To be an average analyst is fairly simple...

.... all you have to do is go to all the meetings, complete all the mandatory training courses, and listen to feedback from your manager.

But...

IF you want to be a GREAT analyst - if you want to truly be successful THEN that's not enough.

To truly succeed, you need an internal drive to continuously improve your skills and knowledge.

Systems Analysis, like any other profession, requires specialized skills and knowledge...

... and to be effective you need to develop in three key areas:

technical skills,
business domain knowledge, and
those very subjective soft skills.

Technical Skills are the foundation of your career. You surely would not trust a doctor who tells you that he's seen somebody else doing that surgery...

...but I brush against this scenario all the time when I interview systems analysts. When asked about his claimed expertise with "class diagrams", one such candidate told me that he once worked on a project where "they" used class diagrams. Who's they?

Technical know-how are those skills which are very specific to your profession. In our case it's use case modeling, object oriented analysis, Data Flow Diagrams, problem solving patterns, user stories, etc.

For starters, study and keep understand the methodology and best practices used in your place of employment. Then venture out on your own and learn a new skill. Pick up a book on agile stories - read an article on sequence diagrams - take a UML course.

Business Domain Knowledge, also known as vertical market knowledge, empowers you to easily grasp the requirements and to quickly spot problems within a given solution. A technically correct diagram is useless if the business information represented is wrong.

Mortgage Banking is our domain, specifically mortgage loan origination... This is a highly complex and challenging industry.

Up to the challenge?

Soft Skills are what distinguishes a good analyst from an effective analyst...

...you may have the best solution, but if you can't communicate it - the solution is worthless.

...you may have a great idea, but if you can't convince your manager to adopt it - it's useless.

...you may manage skilled analysts, but if you can't inspire them - your team will fall apart.

Soft skills are critical to Your success!

So... learn to negotiate... improve your communication skills... be quick to listen and slow to speak... increase your sphere of influence... inspire!

What do you think?

Adrian

Come to me with problems, not solutions

Pjbussol — Fri, 28 Mar 2014 20:06:00 GMT

“Bring me solutions, not problems”. How often have we heard those words uttered by management? In the main it’s a sensible ask however, for a Business Analyst, quite the opposite is true. Our job is to define business problems when often we are presented with solutions.

“We need a new reporting tool because the MI we receive isn’t always correct”.

We could initiate a project on this basis; gather detailed requirements, develop a new reporting tool and roll it out across the organisation but would this address the issue and if it did, would it really be the most effective way to do so?

Could it be that there is a problem with the data entry or with the way the MI is being interpreted?

The above problem statement is merely a symptom of a problem and does a poor job at describing what the real problem is.

Would a Doctor simply prescribe pain killers to a patient who complains about headaches or would he probe further, try to identify the reason for the headaches and offer treatment accordingly? So too must the Business Analyst probe deeper and recommend appropriate options.

The above illustrates why we cannot always rely on stakeholders to provide an accurate problem definition alone. There are other reasons too. For example, different stakeholders will have different (and sometimes conflicting) perspectives on the problem and for that reason, it is essential that the right people are engaged and the right information is elicited.

CFO - “We need a new reporting tool because the MI we receive isn’t always correct”

MI & Reporting Manager - “I need more resource because the demand for MI exceeds our current capacity”

Senior MI Analyst (Team Lead) - “There is too much re-work” “Team morale is very low”

MI Analyst - “The reporting suite is to complex. The MI that I provide is always correct but I’m often asked to redo work with slightly different parameters”

Night Watchman - “I’ve no idea. All I know is that boy seems to work awfully late!”

So maybe you might not interview the Night Watchman – but useful information does often come from surprising places!

In order to develop a true problem definition we must explore and challenge all of the problem statements that we have captured. In reality, there will be many and we must analyse each in turn to develop a short list of problem candidates.

There are many ways to explore the problem statements some common techniques are:

- 5 Whys

- Root Cause Analysis

- CATWOE

An explanation and templates for these techniques are readily available online.

Once we have our problem candidates, we should assess each of them in turn to determine whether they are in scope, relevant, a true problem or feasible. This should then lead to a clearly defined problem definition or in some instances a number of defined problems. When a number of valid problems are identified, the Project Team and Sponsor should decide which one to address.

So, the final step will be to get the problem owner to confirm and accept the problem definition but remember, never, ever go to management with a problem! Not without an appropriate solution anyway!

- See more at: http://www.peterjefferies.co.uk

What do you do?

Pjbussol — Mon, 18 Nov 2013 23:14:00 GMT

“So, what do you do?” It’s quite probably the question I most dread being asked. It’s a fairly benign question but as a Business Analyst I feel compelled to assess and understand what I am really being asked before attempting to provide an appropriately pitched response to my inquisitor. I find myself scrambling for the right words whilst my inner-voice is assuring me that whatever answer I give will most likely be met with confusion and probably even a little irritation.

“I am a Business Analyst” I awkwardly mumble – blushing out of embarrassment for the both of us – whilst preparing for the inevitable follow-up question…. Don’t get me wrong, I love my job and can passionately talk about it. The problem is, unlike a Project Manager, for example, the role of a Business Analyst is not clearly defined – You've got to love the irony!

The Business Analysis Book of Knowledge (BABOK) includes a standard definition of what a Business Analyst does. However, every Business Analyst, Project Manager, Hiring Manager etc. will have their own understanding and set of expectations. The truth is I don’t do any one thing. On any given day I could be mediating a heated discussion between a solution designer and a CFO in the morning and in the afternoon ordering doughnuts for a design workshop (tip: a great way to prevent any future mediation!) Sure, a Business Analyst needs to be skilled in lots of things and may be accountable for producing this document or that document, but these things should not define us and are poor indicators of the value we bring to a project. Every successful project starts with an idea but what is ultimately delivered is often very different indeed. The idea matures and flourishes and it is the job of the Business Analyst to cultivate and manage this change. We navigate the project through its life-cycle. The Project Manager might be in the driving seat but we are certainly up there next to her, preempting bumps in the road, managing diversions and ensuring the passengers in the backseat continue to enjoy the ride. For me, being a Business Analyst is much, I imagine, like being a parent to a teenage son or daughter – we must be objective listeners, excellent negotiators, understand budgets, have a real grasp on finances and build strong relationships (sometimes with people we don’t necessary want to). We are protective, we are demanding, we are challenging and we are 100% invested in the success of our “babies”.

“So, what do you do?” it’s still a question that I dread being asked, but honestly, I normally just respond with “I work in IT”… That’s normally enough to stop any conversation dead!

Want to be an effective professional? Follow up!

Lee Grinberg, CBAP, PMP — Thu, 18 Jul 2013 17:34:00 GMT

Would you like to be perceived as effective? Want to succeed?

Make sure you follow up.

As a BA you are involved in several initiatives at different stages of development. What separates an average professional from an exceptional one is following up on tasks assigned to others on your projects.

I'm too busy, you say? I don't own the tasks, you say?

Well, like it or not the BA has the primary responsibility of making sure requirements are documented, verified, and validated. This involves input from many sources and it's imperative to get the information in a timely manner.

The benefits of following up include:

Your work will be done on time
People will not forget the assigned tasks
You will be perceived as effective

How will I find the time to follow up, you say? Build it into your daily routine.

When sending an email, flag your email for follow up at some later time. Most email programs have this feature.
When speaking with someone, send them an email summarizing the conversation and confirming next steps. Flag the outgoing email as a follow up item.
Most importantly, follow through and follow up when the email reminder comes up.

In Summary, following up will enhance your job by making you effective. Following up is easily done using your email program and having the discipline to act.

Good luck on your assignments!

How to identify a good (and bad) Business Analyst?

Kunal Jain — Sat, 13 Jul 2013 16:54:00 GMT

Over last 6 years, I have come across more than hundreds of analysts and have conducted almost equal number of interviews. Over this time, I have developed a knack of differentiating best analysts from good and good analysts from bad. If you face this challenge regularly, this post might help you.

So how do you differentiate between good and bad analysts?

Thankfully, it’s not that difficult. I have put a framework around how to judge an analyst. You can use the same to make your life simpler. This framework has it’s genesis in hiring guidelines at Capital One. I have modified it to include additional parameters which I use during interviews.

Structured thinking

This is the most important attribute that distinguishes a good analyst from bad. This attribute is not only required to be a successful analyst, it becomes absolutely critical for a person managing Business Analysts.

So what is Structured thinking?

Structured thinking is a process of putting a framework to an unstructured problem. Having a structure not only helps an analyst understand the problem at a macro level, it also helps by identifying areas which require deeper understanding.

How do I test for structured thinking?

Typically I test this by throwing a open business problem at an analyst and then observing closely how he / she is solving it.

An example is asking a question like: “You have been appointed as CEO of a loss making restaurant at Delhi / London Airport and you are expected to join the company in a week. What would you want to do as a CEO of the company as soon as you join them?”

If the person lays out a nice structure about where the problems could be, he has already ticked one box. If he starts giving you answers out of his hat (e.g. I would be looking at what marketing are we doing?), you should consider it as a red flag. He will not be able to sail through the world of Analytics.

Business understanding and problem solving

There is a reason why Business Analysts are called so and not just Analysts. Until a person understands what he is trying to solve and the business owners are confident that he can solve problems in meaningful manner, he is a dead analyst.

So, how do you test for business understanding?

For an experienced analyst, I typically start judging this by asking about business context for the projects he might have worked on. If he can explain that clearly, it’s a good start. If he can’t, you can almost make your hiring decision here. Next, you can look at the answers a person gives in response to question asked for judging structured thinking. If he gives answers based on numbers only, you need to probe him further. He needs to put a business thinking hat and provide some out of box suggestions.

Attention to details

If a person is not detail oriented, he can never be a good analyst. Every analyst should have the ability to understand business at high level, but he should be able to get down to nuts and bolts of all the levers you might have.

So how do you judge for attention to details?

Start by looking at the CV of a person, has he spent time choosing words carefully? Has he mentioned impact of the projects he might have worked on?

For an experienced analyst, probe on the projects he might have worked on before. Did he consider all the aspects and possibilities? How much time does take to explain his previous projects?

Another way to judge it is by asking the candidate to a guess estimate, something like “Estimate the number of smartphones used in India” and looking at how the candidate answers them. How many factors does he consider to come up with answers? How many segments does he consider to arrive at sizing? These aspects should give you a good read on how detail oriented a person is.

Ability to triangulate numbers & do back of the envelope calculations

While the first three characteristics help you identify a better than average analyst, this characteristic and the next differentiates best of analysts from good analyst. This is an activity I love to do and something I know every good analyst loves. This is the ability to set up equations on page and then do back of the envelope calculations to answer 80% of questions without touching any excel / calculator or laptop. It is also the ability to arrive at a number through various sources and then validating them.

How to judge ability to triangulate numbers and do back of the envelope calculations?

Guess estimate comes to your rescue here. Just ask the candidate to perform the guess estimate on a paper and then ask him to validate the number through an alternate approach.

Communication skills – Ability to tell stories based on numbers

Any analyst is only as good as he can communicate. If a person can not take the complex world of numbers and create a meaningful story out of it, he will always be looked upon as a nerd. He can be a good analyst, but not the best one. Ability to create a story and present it almost has an equal, if not higher influence on your customers and hence increases the chances of success of any analytics project.

How do you judge communication skills?

You can get a sense on this through the entire interview. If this is very critical to the role you are evaluating for, you can provide datasets in excel and ask the person to present some open ended questions

Hopefully, this framework will help you for any analyst hiring in future. In case you have some suggestions, do let me know.

Kunal Jain

Blogger, www.analyticsvidhya.com

kunal.jain@analyticsvidhya.com

How to convince stakeholders of BA value for the first time?

Lee Grinberg, CBAP, PMP — Fri, 21 Jun 2013 13:46:00 GMT

In my previous posts I outlined how I was able to succeed being the first and only BA at a company and the importance of establishing trust between you and the stakeholders.

So you're the first BA at a company. All are looking at you and thinking what can this person do for me?

Good question. What can you do for them?

Show them how your contribution will make their life easier!

I'll tell you how I handled this challenge. I was brought in to write functional specs based on business requirements. The business requirements were good but not complete. The IT folks were afraid that key use cases were missing.

I took the following steps:

Created a context diagram (first one in the company) to show them what scenarios may be missing
Created use cases from the business requirements
Reviewed both with the SMEs. This uncovered many gaps not covered by business requirements

Once gaps were uncovered, the people writing the business requirments were relieved to know the gaps were identified early in the process and not in a later (embarassing) stage. I made their life easier and this was appreciated.

The next steps were around design:

Wrote a detailed functional spec outlining database and functional changes
Clearly wrote out testing scenarios

So what, you may be thinking. After all, this is what BAs do. True, but remember, I was the first and only one in the company so no one was convinced of the value of a BA.

The result of design was that developers were relieved to know they didn't have to have lengthy conversations with the end users about functionality.

The key concept again is to make their life easier!

Once trust is established, however, you must prove that you can benefit the stakeholders.

Do you want stakeholders to trust you?

Lee Grinberg, CBAP, PMP — Mon, 03 Jun 2013 12:23:00 GMT

Do you want to be an effective BA?

The first step is to make the key stakeholders trust you.

As I wrote in my previous post it is the first step in establishing yourself when you're the only BA in your organization.

When I joined and sat down for my first meeting with the project team not only was I met with stares of hostility I was also leveled with questions regarding the need for my role (gasp!) The project sponsor and his right hand who was developing business requirements were feeling threatened and did not want to give up control.

So, how to make them trust you? Develop rapport and give credit!

First, develop professional rapport. Over a few months, I met with them to clearly establish my boundaries (writing functional specs) as opposed to stepping on their turf (business requirements) and to offer my help with clarifications whenever I could. I learned their business terminology and got my hands on as much system information as possible. In the process of developing rapport, I was also learning about the system and became a better BA. This went a long way to establish my earnestness and good intentions.

Second, develop a personal rapport. I got to know these guys pretty well. We had a few drinks, shared personal stories, and trust soon developed. I also asked them for help in navigating the organizational culture. When people help you, they trust you.

The final watershed moment that made them trust me happened in another project meeting. I was doing a presentation on the state of the project to senior management and when the time was right stopped and gave credit to the guys who started it and kept it rolling. I took no credit for myself. This completely established my good intentions.

So, what finally happened? These stakeholders and I have a great working relationship which outlasted the original project.

Are you the first and only one?

Lee Grinberg, CBAP, PMP — Sat, 25 May 2013 11:04:00 GMT

Are you the first and only Business Analyst in your company? If so, you know how hard it is to survive while doing your job and bringing about organizational change. If not, you may be frantically thinking "How do I get out?!".

This post is to share my experience in how to not only survive but thrive!

I joined a mid-size company where there was no Business Analysts or Project Managers. On top of this, the IT team was new with little knowledge of the system. There was an SDLC (sort of) that was being followed but the requirements gathering went something like this:

Business user wants something but he's not so sure what
He pops by the IT department and blurts it out to an unsuspecting developer
Developer codes something the developer is sure the business user wants
QA talks to the business user and developer to figure out what they really want to test (no test plan or testcases)
Go live date and the next few days - chaos as bugs appear and no one quite knows how this happened (again and again)

So by now you're thinking I was marching off to the SVP of the company with a copy of BABOK in hand in a self righteous indignation, right? WRONG.

Open confrontation would only create resentment on the part of the entrenched business and developer community. Instead I laid low for a while, observing taking notes and thinking where I would make corrections.

I made changes slowly following the steps below in order:

Developed relationships with influential stakeholders. Relationships go a long, long, way towards acceptance.
Started writing down requirements and showing them to the business stakeholders. Reactions were "Wow, you really got it" or "This is not what I meant at all, here's what I really meant....". That's the idea, get them to acknowledge what they really want.
Learned the database structure so that my requirements could refer to tables and even specific fields. I know, I know this is not what a BA should do but... with a new IT team it was best.
Produced a detailed spec which was the sole document used for development and QA. All stakeholders were now on one page.

The above was done on a small project. This way I didn't "rock the boat". Since the results were much better than the status quo, my perceived value to the business and IT went up a notch. Since I could now speak a little businessese and ITese I also got some respect.

There was much more to do of course and the four steps above are just general highlights. More details on how to implement them in further posts.....

Breaking Through the BA Mystique

palvarez — Tue, 11 Oct 2011 18:13:00 GMT

You can’t work in IT and not have watched “Office Space.” I mean, it’s a prerequisite, isn’t it? It’s like being a developer and never having heard “Code Monkey.” It’s the type of movie where you sit and nod as you laugh, recognizing it is funny because it is true.

My favorite dialogue in the film is between Bob Slydell (one of the Bobs tasked with downsizing Initech) and Tom Smykowski (a targeted employee).
- Bob Slydell: What would you say you do here?
- Tom Smykowski: I deal with the customers so the engineers don't have to!”(paraphrased)

In many ways, that line summarizes the role of a business analyst. Or does it?

It sounds like a simple question: “What do you do?” It’s the second most important thing that is communicated between two people when they first meet. And in most cases, the response is rather simple.

Well, for a business analyst, the “what” can sometimes be difficult to explain. Following the words “I’m a business analyst” I tend to get wordy and I ramble on trying to find the right words to communicate what I do on a given day without going into the specifics of the project on which I’m currently working. Because, after all, it always depends on the project, doesn’t it?

It’s easier to define the “what” in a complex software system than it is to explain what a BA does. It’s what a certain manager I know once referred to as “The BA Mystique.”

Now, that “mystique” can sometimes serve us well. It’s what gets people to our meetings. My theory is that we often fill conference rooms and conference bridges with user reps, project managers, developers, testers, etc., simply because they want to satisfy their curiosity about what is it the BA does here.

For the most part, however, the mystique hinders us. It prevents us from focusing on the project scope, the requirements, and the task at hand, because we spend so much of the time allotted to analysis proving our worth to the team – defining our role and its benefits, explaining our methods, our document templates. Even after 15+ years, I still find myself defining my role with the onset of every project.

The BA Mystique exists across many IT organizations. It is often seen in managers who are not quite sure what to expect from their BAs. However, what is somewhat surprising is when that uncertainty comes from business analysts themselves. Only ask a colleague from a different company – no, scratch that, from a different department in your own organization (and sometimes even within the same department) – what he or she does as a business analyst.

It is a common theme at business analysis conferences, blogs, BA communities and organizations - many business analysts look at the work they are currently doing and wonder whether they fit the BA mold. The business analyst role has become a mystery to them. So, how do we clear things up? Well, it all starts with you and your desire to investigate, to learn.

Read. Resources for business analysts are more accessible now than they have ever been, in large part due to the increasing interactivity of internet sites. Business analysts and managers who have broken through the BA mystique are blogging about it, chatting about it, teaching free webinars, and writing books about it. All you need to do is a simple Google search on "business analyst" and you have access to about 56,700,000 references of knowledge and experience. But it is even easier than that! Browse through the Modern Analyst site and pore through the articles, discussions, and advice posted by your fellow business analysts. Read. Tap into the BA resources and read. You will find others with the same concerns and will learn much about where you may fit as a BA.

Talk. Discuss. Elicit information from other business analysts. Ask them what they do. And not just those in your department or specific division. Reach out across the organization and see what others are doing. You may find that the work others are doing is exactly what you've been looking for - or perhaps not. Whether you find a place where you fit, or not, at least you know what is the current landscape.

And then, try it. Try doing the work and see how it fits you. When you talk to the BA leaders in your organization ask them to give you some practice work - a case study, if you will - that you can take and run with. I have always found other business analysts eager to help their colleagues, without exception; I am certain you will find them willing to provide guidance. Ask them for a sample project and write the requirements, draw the business process models and activity diagrams; take it upon yourself to feel what the work is like. Perhaps you'll find the work dull and unsatisfying. Or, you may find it challenging and enjoyable (yes, enjoyable).

After all, it is up to you. It is up to you to find out all you can about the BA path - take advantage of the resources, talk to others in the field, learn from them, and try on the work so that when you have that next career discussion with your manager it is one that will lead you in a direction in which you will be glad to travel.

The Role of the Requirements Analyst in Driving Specialized Development Teams to Success

Seilevel — Sun, 27 Feb 2011 15:11:00 GMT

I am working on a project where Development teams are divided into specialized areas called Centers of Competence. For example, one team works on Customer data, another team on Product data and validation, another works with the Shopping Cart, another with Checkout and so on. Requirements are gathered within each of these Centers of Competence and handed off to Development for implementation.

The above approach works very well for modular functionality that is specific to a Center of Competence. For example, features specific to Customer Create are usually handled within the Customer Center of Competence and do not impact any of the other teams. But when Customer data flows from one team to another to be used further downstream for pricing, taxation, product segmentation and so on, the modular structure of requirements definition and development breaks down.

This is where the Requirements Analyst plays a crucial role in ensuring that proper functionality is developed. The key techniques we have used to ensure requirements flow across the modular functionality boundaries are as below.

1. Identify all development teams impacted by a requirement or feature request. For example, some specific Customer data may need to be captured to ensure proper pricing and taxation. These requirements will likely originate within those specific Centers of Competence, but will be developed by a different team. So, the analyst creating the requirements will clearly identify the impacted teams other than just his or her own Center of Competence.
2. Communicate clearly to impacted development teams the functionality they need to develop to support requirements in a specific Center of Competence.
3. Get estimates of time to develop, test and deploy from the other impacted teams. This is tracked as a separate task that must be completed prior to requirements being signed off for a release.
4. Conduct cross functional development and requirements meetings so that all impacted teams clearly understand the functionality that needs to be developed.
5. Define clearly the interfaces through which data and messages flow from one sub-system to another. Document any specific data requirements necessitated to support these interfaces.
6. Ensure that the test teams understand the implications for both unit testing and feature testing. There are typically two test teams to deal with. One test team works with a Center of Competence and the other is the global team that deals with the entire application.

All of the above tasks are managed, facilitated and executed by the Requirements Analyst. A good grasp of the overall application, a thorough understanding of data flow, an excellent working relationship with different teams and top notch facilitation skills are keys to success.
Good Requirements professionals managing both their individual areas and coordinating across boundaries are key to the success of the Center of Competence method of dividing and managing Development teams.

Five New Year’s Resolutions for Requirements

Seilevel — Fri, 14 Jan 2011 21:38:00 GMT

It’s that time of year, where our thoughts turn to the holidays…the holiday parties, the shopping, the lights, visiting with family! For many organizations, the end of the year tends to be quiet on the IT front, for no organization wants to risk introducing problems into their production environment at year end.

So as I look back at this year on what was accomplished, I tend to do a mini-retrospective on my year…what went well, what did not, and what can I improve? Thus looking at those items to improve, I’ve come up with a list of New Year’s Resolutions to focus on for next year:

Use the ROM – Requirements Object Model

Understand what the business problem is trying to be solved for any project that I am working on. This can be difficult to get on any project, but essentially, every project should be attempting to solve some business problem. Usually these problems are rooted in money.

Once the business problem has been identified, the business objectives can be defined. And from there, the strategy to meet those objectives can be defined.

The benefit of understanding the business problem is then you are developing a solution that will provide a return on investment. No one wants to do a project just because, there should be a purpose and it should be valuable.

Write Clear Concise Requirements

Of course I always try to write clear, concise, testable requirements. But what seems to be clear, concise and testable to me may not be in reality. So I always consider this an area of constant improvement.

How can I ensure that I am writing clear, concise, testable requirements? Reviews are always a great idea. Get another set of eyes on what you have written. I like to get a peer to review my work before sending it off to my client, and preferably, someone who is not very familiar with my project. The less they know the better. For if they can understand the requirements, and then I feel like I have done a decent job in getting them document.

But these peer reviews do not take the place of reviews by the business. They are the ultimate authority, and definitely need to be done to ensure correctness and validity.

One final word on this topic and it may sound silly to state this, but I see many mistakes made because of it: spell check does not replace proof-reading. Spell check can definitely help you ensure that the words are spelled correctly, but it cannot help you ensure that you have the right words. I’ve seen embarrassing notes go out…the words were all spelled correctly…but one wrong word could mean big trouble!

Ensure Better Transparency

Transparency means being as clear and upfront with regards to the progress and status of your project. One way to help ensure transparency is to provide status reports.

I try to send frequent and consistent status reports help provide information on how the project is progressing to those who need to know. These reports should include information such as what was accomplished that week, what was not and why, what is planned for the next week, and any risks or issues that have arisen. This information helps me keep a running record of what has happened in the project, and can help refresh memories when people have forgotten what has been done.

They do not have to take long to create, especially if you create a template, and if you are consistent with sending them out, they become part of your routine.

Do Requirements Traceability

I try to ensure that all requirements map back to the stated business objectives. This helps ensure that no business objectives have been missed, but also helps prevent scope creep.

While we all know that traceability is a good thing to do, it is laborious and tedious to do, especially outside of a requirements management tool. As requirements are written, reviewed and edited, maintaining traceability can be very difficult. I try to wait until later in the requirements definition process can save some work; however, I have to be careful about waiting too long. If I wait too long, then I may miss a chance to add missed requirements, or to prevent scope creep.

Use Models

Finally, I need to use various models to describe requirements. There is no one model that can demonstrate a set of requirements fully and completely. A combination of several models allows the requirements team and development to see the requirements from several different perspectives. It helps us gain a full understanding of what is being requested, and helps ensure that there are few misunderstandings.

While it may be easy to say “use models”, it can be a challenge to get an organization to do so. People get comfortable with their current process, and can be reluctant to change. They may resist the introduction of anything that is perceived as more work. To get around those that are resistant, I try to constantly show how the model s adds value. I remind other business analysts and product managers ultimately, the models are not for them…they are for the business to confirm their requirements, and they are for development to get a full understanding of what is desired. We are in the business to help others clearly define what they need, and to help deliver those results.

Finally, I would like to wish all of you healthy, safe and happy holiday season!

Want more on requirements and requirements models? check out our other posts.

http://requirements.seilevel.com/blog/

Coaching Football and Agile Applications: It’s Game Time

Mendix.com — Tue, 04 Jan 2011 13:53:00 GMT

Many business analysts and heads of industry find themselves in compromising situations. Their team is down and they can’t seem to move the business properly towards the goal. It seems your competitor across the field is always one step ahead, providing results and fan [customer] satisfaction. But how did they do it and why can’t you come back?

Game Planning

This powerful opponent of yours has come up with a great game plan. The product they use – whether it’s the right gloves, cleats, breathable uniforms, etc. in sports – or a better system from order receipt, to entry, to delivery in business – is fundamentally better… but why? Did this opponent read the weather forecast and plan for adverse conditions? Are they just more talented with players or products that are just better suited for the game? Do they have systems in place that allow for adjustment depending on what is working and what isn’t?

Adjustments

Many of us head into planning a certain way based on what we have and who we’re up against. Let’s say you’re going into the match against the #1 passing team in the league. You spent the whole week practicing your nickel pass defense with plans to stop their attack. But what happens when you get into the game and you realize that their third string ball carrier is a beast? He’s tearing your defense up all over the field. Do you continue to play the pass even though they are running on every single down? No, you need to adjust your game to play with them.

In business it’s the same way, let’s take the classic example of the traditional video store. For years it was all about having the largest selection, being in a convenient location, and providing rentals at a reasonable price. In comes a new team with a new strategy, let the customer handle every transaction online without ever having to leave their house. Some of the traditional storefronts adjusted, downsizing locations and adding a similar online offering to their large customer base.

How does this all tie together?

Much like the coach that is able to switch his defense to line up eight in the box against the team running all over them, the large video store needs to be able to position itself against a competitor’s strategy. But what if this company doesn’t have the ability modify its business strategy? What if they need a complete overhaul of its application infrastructure to do so? This is going to cost the business large amounts of time and money. The money will absolutely have to be spent if the company wants to stay in the game for the long haul. But what about the time it takes to develop the application?

Many of the mid-sized video providers didn’t have the brand, size, nor money to bridge them into this new age of video rental. By the time they were able to come to market with a suitable offering, they were competing against the other small companies who also didn’t adapt fast enough. Do yourself a favor and build your original application on a platform that is agile and can change with your business needs. That’s the moral of this story – agility wins.

BA Careers - Is industry experience more important than Analytical skill?

HSantanam — Mon, 06 Dec 2010 19:32:00 GMT

Business Analysts often delve into business requirements, gathering, understanding and documenting business processes and functions. An analytical mind and detailed information gathering are considered to be essential; one wonders though, if industry experience is a must for good business analysis skills. After all, if you knew well the ins and outs of the industry you were in, that’s good, right? The answer is probably, but not always. Why is that?

Business analysts, like developers and solution architects, are trained to think logically and focus on specific issues at hand. Once in a while, though, they need to step back, and like a painter evaluating and assessing his painting-in-progress, assess their progress on the task at hand and be prepared to explain it to a wider audience in plain talk. That, in my opinion, is an essential skill of the modern analyst.

First, industry experience means less time is wasted knowing the industry environment – the general models the business follows, what regulatory and competitive arena it is part of and some common terminology. Secondly, business process flows are easier to understand, say, if one was documenting business process flows for a financial transaction, if that person had already worked in a financial services firm in a financial transaction environment (e.g., Front office, where the deals were made, or the middle office, where financial and regulatory processes were checked or filtered, and the back office, where the transactions were processed and settled – and where exceptions were followed up for closure).

That of course, brings up an interesting question – if a business analyst goes into an unfamiliar environment, how much time should be spent learning the business environment? Wouldn’t that leave less time for focusing on the essentials of requirements, elicitations and documentation? And how valuable would all that be, anyway? After all, time is money – and with workloads being what they these days, such knowledge, while good for a progressive and open mind, would be quite expensive indeed, wouldn’t it?

The answer is that depending on the timeframe, it would be beneficial to get the most important work done first, which would mean skipping the overview on the business. In a limited time frame, a “bullet-point” information dissemination method (summary) might work. Asking questions in the right environment is healthy, but learning important concepts on one’s own time is a better idea. After all, stakeholders have limited time available even for requirements – they might not have the patience for an extended basics class. On the other hand, workflows and the reasoning behind them should be questioned to extract the maximum value for optimization and better business.

What about the times when it might be beneficial to hire a business analyst who is sharp and curious, but not industry-knowledgeable? When the existing patterns are so constricted and “inside the box” that a fresh perspective is needed, hiring analysts without a lot of presumptions and insider’s knowledge is actually a good idea.

I worked in a firm once where I was asked to interview, evaluate and recommend IT candidates (mostly developers, some analysts). At the end of the face-to-face interview, I would ask the candidate to solve a problem on pen and paper. The rules were clear – no writing code, simply writing out the solutions – a diagram was acceptable as long as it wasn’t too complex. Additionally, the answer had to be limited to 1 page and be completed in about 30 minutes. I was amazed at how the smartest candidates failed this written “test” – it was actually quite simple, for it did not require deep industry knowledge and did not put the candidate on the spot by testing coding knowledge. I simply wanted to know how the candidate thought about solving problems and whether he/she was able to put it on paper. I often got several pages of answers, written code and requests for extending the time available, though all the requirements for the written test were explained before hand. Needless to say, these candidates were not hired.

Capacity review - assets planning

HSantanam — Fri, 19 Nov 2010 15:42:00 GMT

Capacity review

Why should Business Analysts be concerned about IT Asset Capacity planning / review - because business analysts, in my opinion, are all about optimizing business processes - in many cases, closely linked to IT. With that said, here is some food for thought:

IT Asset management - One of the core principles for Information Technology is "Confidentiality, Availability, Integrity". As business fluctuates and product and transaction cycles speed up ever more, it is very important, useful and in the vested interests of IT Management to perform a Capacity review periodically - due to the cost and complexity an annual review might be sufficient in most cases. What exactly is Capacity review anyway? In its simplest form, it is ensuring that IT assets - hardware, software and connected links (networks, telecommunication access to/from the internet, cloud etc) and storage - are sufficient to meet peak demand as defined by company policy or best practices. If one doesn't exist at your organization, review best practices at similar firms in your industry and define it and seek approval. As an example, one brokerage firm that I worked at had a policy that required that the main brokerage applications had to be capable of handling twice the capacity load of the busiest day of the year. So if the servers on the busiest day were at 45% of capacity for an extended period of time, then as per management's requirement, the capacity of those servers had to be able to work at 90% load.

One of my roles, in the many hats that I wore, was to do a capacity review for all the distributed applications at the end of the year. To prepare for this, I first went to our metrics site, where I sifted through reams of data on all the web servers, application servers, database servers etc. Then I organized the data into spreadsheets where I sorted through page views, server resource loads etc. Based on the data at hand, and using algorithms developed in-house, and by looking at the back-end (mainframe, database) data and connectivity analysis, I had a map of how much capacity was used on the distributed side and in-bound and out-bound feeds. That gave us an idea of whether the distributed servers could handle the capacity required for an unusually busy day (think of a very volatile day in the markets - major business collapse, terrorist attacks etc). This is only an example of a specific industry - but such capacity reviews are de rigueur in every industry - telecommunications, transportations, and retail are some that come to mind.

On the software side, analysts and reviewers could simulate many things - online transactional processing simulation, for example, is common. But it might be more useful to ask about the connectivity - sure, the retail front-end web site can take 10,000 orders a second, but can the back-end handle it? Can the connections to the credit checks work successfully and simultaneously at that level? How about order fulfillment - do the fulfillment centers/warehouses have the capacity to handle huge backlogs - if not or unsure, how long would it take and more importantly, can orders be tracked adequately? Can the supply chain handle it - can it be tested? Has it been tested? If these processes are outsourced, does the vendor make any explicit guarantees in the contractual agreements? How often do they test, and how willing and able would they be to do a simulated test (note: these are different from a disaster recovery test, which normally only simulate average loads at a backup site or offer an alternate way to do the same thing you already do).

Capacity reviews are also useful in incorporating forecasts into future budgeting and for justification purposes. Additionally, as technology moves forward at an ever faster pace, old IT assets can be updated, upgraded or replaced by incorporating these reviews ("These 25 servers operating at 90% capacity can be replaced with 5 new ones operating at an average of 50% - and a payback period of 1.5 years"). This will also show management that you and your team have done your homework with substantiated facts.

Another way such reviews can assist is in finding underutilized resources - and at a time of budgetary pressures, might come in handy. For example, for a new application project with limited budget, I was able to point to underutilized servers (which, of course, I knew from my capacity planning exercise) which could host the new app. By sharing resources (servers, existing software licenses on those servers, and storage and network charge backs as well as backup site servers) costs were mitigated.

Capacity Review is a tool that business analysts and business-IT process / operations managers can use to plan, streamline and optimize their assets and thereby provide more value to the business.

My blogs can also be viewed at:

http://business-it-knowledge.blogspot.com/

Career Possibilities for Business Analysts-expanding your horizons

HSantanam — Wed, 17 Nov 2010 16:55:00 GMT

You have achieved your short term BA goals. You want to expand your horizons and see what else is out there and how you can progress in your career and gain knowledge and keep your career up-to-date as well. What are some of the possibilities out there that won't force you to re-learn something new from scratch? Some possibilities for career and knowledge expansion in areas related (or of possible interest) to Business Analysis:

Project Management: The PMP (Project Management Professional) certification from the Project Management Institute (www.pmi.org) is valued by many employers. Business Analysts, I believe, are well-suited for project management, which aims for successful completion of projects from inception to closing, while managing (juggling?) competing constraints of time, cost and scope. The PMBOK (Project Management Body of Knowledge), which is similar to BABOK, is a framework used in implementation of best project practices regardless of industry or project scope. The concepts used in PMBOK would be familiar to anyone who knows BABOK - for example, processes in the knowledge areas have inputs, tools and techniques and outputs. The PMP certification is valid for 3 years and may be renewed by obtaining training or other credits known as PDUs.

Information Systems Security: The Certified Information Systems Security Professional (CISSP) certification from the International Information Systems Security Certification Consortium Inc - "ISC2" for short (https://www.isc2.org/) - is also in demand for professionals catering to security related aspects of Information Technology - from IT systems architects to developers to Audit, Compliance and Risk managers. The CISSP Common Body of Knowledge (CBK) covers 10 domains - Information Security Governance, Security Architecture and Design, Cryptography, Physical Security, Access Controls, Applications Development Security, Legal-Regulations-Compliance and Investigations, Business Continuity and Disaster Recovery Planning, Operations Security. The aim is to instill a comprehensive overview of the various aspects of the IT environment and how they all relate to security and best practices. Like the PMP, the credentials need to be renewed every three years through training, volunteering in ISC2 programs or other related knowledge.

Some other certifications from ISC2 that may be of interest:

Certified Secure Software Lifecycle Professional (CSSLP) (https://www.isc2.org/csslp/default.aspx) : As the name implies, the certification is for those involved in the software lifecycle and is concerned with building security into the entire Software Development Life Cycle. It deals with secure software knowledge in the design, implementation/coding, testing, acceptance, deployment, operations, maintenance and disposal domains.

Systems Security Certified Practitioner (SSCP) (https://www.isc2.org/sscp/default.aspx): According to ISC2, this title is good for Network Security Engineers, Security Systems Analysts and Security Administrators. So Business Analysts who want to learn more about the security area and become experts may consider this.

The CISSP certification can also be obtained, in addition to the general CISSP described above, in specializations ("concentrations") below:

Pasted from <https://www.isc2.org/concentrations/default.aspx>

Other certifications currently in demand include:

ITIL (http://www.itil-officialsite.com/home/home.asp) - (Information Technology Infrastructure Library) which is a set of concepts and practices for Information Technology Services Management. It deals with management , delivery and support of IT services to business - which would be ideal, for say, managing a hosting area, data center, software as a service, change management and well..you get the idea.

Certified Information Systems Auditor (CISA) from ISACA (originally Information Systems Audit and Control Association, now known by its acronym only)

For Business Analysts who think they have a knack for probing IT systems and ensuring that process conform to policies and want to pursue an IT audit/Compliance career, the CISA might be a good bet.

Other certifications from ISACA in a similar vein include:

Certified Information Security Manager (CISM) - for those who design, build or manage IT security programs.
Certified in the Governance of Enterprise IT (CGEIT) - for those involved in IT governance.
Certified in Risk and Information Systems Control (CRISC) - for those involved with risk assessment/evaluation/monitoring/response etc.

Information on the above certifications can be found here: http://www.isaca.org/CERTIFICATION/Pages/default.aspx

There are many other paths to expand one's career horizons, depending on interest, time and inclination - Solutions Architects, Enterprise Architects, Database analysts and Network specialists are only a few - business analysts, due to the detailed nature of their work, are well positioned to transition or acquire new skill sets.

The emerging field of Wireless application specialists - mobile apps, application security (wireless protocols, app security design etc) is also lucrative. As mobile technology and gadgets (smart phones, tablets etc) get more mature, more business functions will add on mobile functionality.

If there are other interesting accreditations, certifications or knowledge programs that I have missed, I would love to hear about it…Thanks

HS.

Learned Processes

Seilevel — Tue, 26 Oct 2010 18:59:00 GMT

I know you are going to call me crazy, but I just have to let everyone know. Machines are controlling us. Don’t say I didn’t warn you. You don’t believe me? Okay, I’ll explain.

People come and go in organizations. Systems tend to stay much longer. Simple enough right? Here is the kicker. When that system was implemented, it was implemented to solve a problem. But it did not have all the capabilities required to solve all the problems the business had. So in order to fix the big problem, lots of little problems sprung up.

They weren’t an issue of course because the business had workarounds, usually manual ones. No biggie right? Well, maybe.

Let us say it is five years later and the original people who worked with the system are gone. The replacements were only trained on how to follow the process and not why the processes should be followed. There is the start; the machine has people doing its bidding.

Then a few years later it is decided that some systems should be replaced. So when all of the requirements analysts come in to do their thing, they document the process as is from the users and SMEs. This then gets propagated to the new systems. And thus, the old system lives on through the new system. The old bugs are now required functionality.

We must stop them! When working with old systems and processes don’t just ask what the current state of affairs is. Be sure to ask why it is done the way it is. This was happening on one of my previous projects. The inabilities of the old system were being written into requirements for the new system. Unnecessary needs for manual selections and processes were being maintained.

The project was so large and unruly that other requirements analysts would simply write down the current process and confirm it is how things work. This practice caused very complicated user interactions during the sales process and contract creation. After the fact, people realized that they should have automated more and asked the user questions about what to do less.

Because the software being implemented did not come with all this added functionality, it ended up costing the company much more money to reevaluate what was really needed, what could be covered by alternative existing features, and what would just go unimplemented.

By JHEEP

Want other software requirements posts? http://requirements.seilevel.com/blog/

Enter the Business Engineer

Mendix.com — Tue, 05 Oct 2010 13:53:00 GMT

At Mendix, we find that our customers appoint a particular kind of person to work with our products. Sometimes they’re from IT, sometimes they’re a business analyst or project manager – in any case, they practice the skills of both fields. Times are changing, departmental lines are blurring, and a new breed of business superhero has risen: the BE.

The ‘Business Engineer’ – who are they, what do they do, and why you want to know them.

Who

Until now, these men and women of myth have appeared under the guise of your organizational boundaries – half business and half IT. As champions of business modeling, they dance between the ranks of geeks and suits in companies everywhere, aptly increasing business agility at every collaborative junction. With a flash drive dangling from their sports car keychain and first place positions in both Online Poker and Fantasy Baseball, they are what we believe to be the future of the modern business analyst. In this series of blog posts, we attempt to uncover the true nature of this evolved employee…

What

The title of ‘business engineer’ is not completely novel, as it has been used in the past to describe a role similar to that of a business development manager. Under a new light of enterprise software modeling, this term refers to the business analyst on technical steroids – or the IT whiz with a knack for client relations. These skills, once segregated at a basic level of undergraduate education, have merged into a hybrid force of human capital with more creative power than either part could ever fathom.

These collaborative powers can push companies into unchartered profits, as they attribute to the resiliency of a company’s technology. Agility, as readers of this blog know, affords an organization the ability to change with its business environment. The more easily technological change can occur, the faster and more decisive an organization becomes. Charles Darwin says it best: “In the long history of humankind (and animal kind, too) those who learned to collaborate and improvise most effectively have prevailed.”

The business engineer is not a mythical entity – they may even be sitting in the room as you read this post. Finding them and harnessing their abilities should be a primary goal of any manager. In terms of organizational behavior, they are the ‘central connector.’ In terms of organizational culture, they are the ‘go-to guy.’ And in terms of business agility, they are the binding force between business users and technical experts that have never been able to see eye to eye.

Why

The reasons why you’d want business engineers in your company are significant. They make the technology that your company uses easier to use, more intuitive, and they do so faster and with minimal adversity. With the adoption of visual business modeling, and agile development methodologies, these unsung heroes of the enterprise era are here to stay. Do you know the business engineer at your organization? If not, it just might be you.

Why Should We Hire You?, Part I

Seilevel — Wed, 29 Sep 2010 18:49:00 GMT

We look for the best and brightest when hiring for Requirements Analysts and Product Managers. It’s a long and difficult process with many people applying; only a fraction get through the first interview and even less are able to hang in the process as it continues. This has brought great strain to our company: as we expand we simply aren’t able to hire as very few are able to get through our arduous interview process.

Recently, we went to the University of Texas at Austin looking for interns and entry level Requirements Analysts. They asked many questions, mostly along the lines of “what does Seilevel do?”, “what would a typical day look like for me as an RA?”, “what’s the mentoring program like?”, and “what qualities do you look for in a potential new hire?”. I would like to address the last question now, to give the potential candidates out there an idea of what kind of person we look for.

Most importantly, we look for those in whom we see great potential. Can we teach and train this person? Will she be receptive? Is she able to adapt and change to the ambiguous and sometimes difficult environment? Is she smart enough to resolve tasks on her own when others are too busy to hand-hold? To get an outstanding “Yes” on all these questions is the first test to pass. When we talk to people, we want to address these questions indirectly with candidates. This means that we most likely won’t ask these questions in the form as written above, but we probe to elicit answers which give clarity to the aforementioned questions.

People are smart. Sometimes, we want to give a solution to a problem so badly that we neglect to listen to the entire problem. We look for candidates that are patient enough to listen to a whole problem before recommending a solution. As consultants, our clients look to us to solve their problems, so it’s very important that we all know how to listen. Good listening skills include maintaining good eye contact, maintaining attentive posture, and being able to summarize the problem with different words to show you understand what the issue at hand is which also uncovers underlying assumptions.

Gathering requirements includes many hours of asking probing questions to the business in order to gain a clear understanding of what the product needs to do. We want people who instinctively ask the right questions. This is a hard item to teach, so we are looking for those who have the critical thinking skills which enables them to have these types of constructive dialogues.

We want someone who works well under pressure. From school, you’re hopefully used to completing projects or papers with strict deadlines and occasionally working long hours to ensure you get that paper or project perfected. Oftentimes on a client site you will encounter strict deadlines, as each man hour over a deadline is quite costly. We’re looking for those Type-A personalities who know what it takes to get the job done well.

Many people who are Type-A and direct communicators can be considered abrasive. What’s the difference between being a direct communicator and being abrasive? We look for those who can communicate with all kinds of people without offending them, which entails being able to change how you say things to suit the recipient. In the US, if a topic is misunderstood or lost in communication, it’s the speaker’s fault, not the listener’s. We look for candidates who grasp this concept. These people can explain the same topic using different words or methods, which better suits the listener.

Prioritization is a must have. When you have a paper for English, a SWOT analysis for marketing, a business review for accounting, and a program for comp sci all due in the same month, what do you do? How do you prioritize? What comes first and why? We always have several hands pulling at our limbs, asking for time in meetings, reviews, documentation, etc. Getting it all done and ensuring client happiness is a delicate art.

My last tip for the day is to ooze confidence! Can you present in front of a room of 20 executives and the CEO? Probably not. (And it may not be a worry here, either!) However, you should be able to speak your intelligent and prepared opinion in a meeting with stakeholders. Don’t be afraid to speak up, with a caveat: as long as you know what you’re talking about. (However, you can always talk it over with another consultant if you are nervous!) As consultants, clients look towards us for answers. We need to study the issue and propose a solution, often on topics in which we may not have formal training, but our logic can trump that issue.

Many of these skills are difficult to teach someone, which is why we look for the candidate who is the right “fit”, meaning that they already possess these baseline soft skills which we can then build upon with requirements knowledge. When preparing to interview, be sure to have prepared situations that you have personally experienced which would demonstrate your capacity to fill these characteristics we look for. Look for Part II of this post next month where we will discuss critical thinking skills necessary to become part of our team.

Are you looking know someone who is? Check out our positions:

http://requirements.seilevel.com/blog/

http://www.seilevel.com/careers/

Mendioms for Business Analysts

Mendix.com — Wed, 01 Sep 2010 13:04:00 GMT

A Mendiom is an idiom with a Mendix twist. This is the first of a series of posts with Mendioms for different types of people. This week, we have chosen a few of our favorite Mendioms for business analysts.

Business analysts are an important part of an organization’s business agility. By having the responsibility of communicating between business and IT, business analysts can greatly reduce time to market of new solutions by using agile development methods. In an effort to both inform and entertain, here are a few slides for my business analyst readers.

Being New 101

Seilevel — Thu, 26 Aug 2010 19:04:00 GMT

Being a relatively new Requirements Analyst/ Business Analyst ( BA) and being new to the industry, I have been blessed with the opportunity to have mentors. Receiving direction from more experienced BA’s has definitely helped me find areas that I can improve on, while at the same time, finding my strengths and improving those too.

Yet there still are challenges that I face while trying to learn as much as possible. For instance, Senior Business Analysts, who are my mentors, will most likely be at client engagements for the majority of their time and it can sometimes be very difficult to find time to teach. Through my experience so far, I have learned a couple of tips that can help those aspiring and budding BA’s out there:

1. Always be on time
This cannot be reiterated enough. I will admit that I have had a slip up myself, but it is crucially important that a junior Business Analyst always be on time.

2. Ask informed questions
Never be afraid of sounding stupid. My mentors would rather me ask a “stupid question” that helps me understand the business problem than floundering about and end up making a mistake farther down the line.

3. Do not assume
Assumptions are bad. Always ask yourself what assumptions you are making when you are creating deliverables for the client. You may come up with some good questions or issues that your Senior Business Analyst didn’t catch before!

4. Use Spell Check
Spell check is your best friend when creating deliverables for clients. Not only does misspelled words make you look less credible, but it can make your organization look less professional too.

5. Take Ownership
Take ownership of the tasks that you are given. Don’t just wait to be fed information and small little projects. Instead, think of yourself being the sole proprietor of the task and think to yourself, “What can I do to make this successful?”.

6. Understanding Communication
Understanding what you are being asked to do is crucial. If you have a small amount of doubt in your mind, that is your cue to ask your Senior Business Analyst for clarification. The last thing you want to do is make the wrong assumptions and create something that the Senior Business Analyst didn’t ask for.

I hope that these little tips will help some of you aspiring and budding Business Analysts out there. I will be sure to add some more simple smart tips in my later blog posts!

http://requirements.seilevel.com/blog/

5 Steps to Improving your Career as a BA

Mendix.com — Tue, 03 Aug 2010 13:28:00 GMT

The community of business analysts in the United States and abroad is taking notice of their impact on the world economy. Not long ago, the idea of a business analyst was new – sitting on the border of technology and business, sharing lunch with both ‘geeks’ and ‘suits,’ and creating value with only the uncanny ability to collaborate between these corporate cultures. These collaborative colleagues will continue to develop alongside, and in between, new technology and new business. The growing popularity of agile methodologies and visual modeling software motivated me to put together this deck of five simple steps to a future focused business analyst.

Much of my research in the business analyst kingdom has led me to believe that the majority of these individuals would do more if they could. In other words, given the opportunity – a good business analyst would talk to the client, write the requirements, build – implement – and test the software, and then provide support to the client for years to come. (Ok, so maybe less credit is due – but you get the point.) Since this magical persona does not exist and may never exist, we can at least give them the tools to delve further into application development. Visual modeling - the ability to visually convey business processes and logic in a manner that both business and IT people can understand - is one such tool. Take it a step further, and allow these business analysts to deploy their models as a living, breathing, application – and you’ve turned a corner in business analyst evolution.

So, to the eager business analyst who wants to get ahead of the game:

Think Big.
Think Balanced.
Be Marketable.
Use Visuals.
And most of all: Think Agile.

How many Business Analysts do I need on my project?

Seilevel — Tue, 27 Jul 2010 15:29:00 GMT

At the beginning of almost every project (and even sometimes midway through them) we are asked to create a requirements plan and estimate the time required on tasks and the number of BAs necessary to execute it. In a later post I’ll talk about the actual plan items, but we do have a rule of thumb for how many BAs you need on a project.

We have a standard metric we use: we suggest 1 BA can support 4 to 8 developers. Typically I suggest 1 BA to support 4 to 6 developers though, as 8 is a stretch on many projects. Of course this number is highly dependent on the context of your project, so treat it as a rule of thumb only.

As an example, right now we have 7 developers working on rebuilding existing functionality from an existing site and it’s required just over 1 BA to work on the requirements for it. And even at that, the BA is pretty stretched to get them done as fast as the dev team needs them. And in another part of the project, we have 1.5 BAs supporting about 4 developers who are doing defect testing – but they are also very intensely focused on UAT activities.

ByJBeatty

How many BA's do you need on your project? Do you have comments?

http://requirements.seilevel.com/blog/2010/07/how-many-business-analysts-do-i-need-on-my-project.html

BA World Sydney - A review

Craig Brown — Tue, 27 Jul 2010 00:31:00 GMT

I went to the Business Analyst World Conference in Melbourne on the 19th and 20th of July. Like last year it was a great event. On day 1 I spent the whole day in one room (introducing speakers.) and got to listen to three very different stories.

Matthew Coppola from Perth training outfit Paramount Training gave a talk on Understanding Strategic Planning.

It’s always useful advice to go back to basics: Where do you want to be? Do you understand your capability? Mathew’s talk gave a simple framework to drill into these two questions. (See a transcripts of the whole talk here.)

Something that struck me while listening to his talk is how odd the world is. So many of us profess to know this stuff, but when you get out into the pressure of deadlines and complicated personal relationships – how many of us stick to the agenda and define the problem sufficiently before getting into implementation mode.

The second talk I saw was by John MacLeod of IBM’s Rational team on Steps to Better Requirements Management. This was the basics of requirements management: Start with a technology neutral business requirement statement, evolve it into a solution constrained by a particular IT or system scope and finally resolve it into specific statements of functionality. And trace things from front to back to keep up with what is getting done and what isn’t.

The third talk was a case study of a project delivered in NSW police by Peter Stanford of Artefaction called Architecting change – from Here to Eternity, or Agile and Now. This talk centred around the problems of getting consensus on big decisions in large, complex and diffuse organizations. The guts of the answer seemed to be making the decisions frequent and small, and using prototypes wherever possible.

On Day 2 I filled in for Paul Culmsee who was unable to attend – and did an ‘intimate’ Q&A session for two tables of people who wanted to ask questions about implementing agile practices. Matt Hodgson and Peter Stanford also sat in answering questions. It was fun and the people there seemed to like the more interactive nature of a conversation over yet another lecture.

The rest of the session was really interesting with lots of good content and speakers. I was happy I went and recommend anyone in Australia (or NZ) to pop along to the Sydney event on the 17th and 18th of August.

(Also posted at www.BetterProjects.net)

Is Your Product Knowldege an Asset or Liability?

Seilevel — Wed, 14 Jul 2010 16:19:00 GMT

There was recently an interesting post by John Mansour on the Austin PMM Forum (registration required) discussing whether Product Knowledge was an Asset or Liability to product managers.

The author makes several claims about how product knowledge is a liability:

“In a nutshell, the more product knowledge you have, the less product management you’re doing because your product knowledge gets you sucked in to a plethora of non product management issues.”

“Furthermore, too much product knowledge leads to micro management – the kiss of death for anyone in a leadership role.”

“Detailed product knowledge = liability because you can’t see the forest from the weeds.”

“Detailed product knowledge = liability because it forces you more into ‘how’ features should work instead of ‘what’s needed and why’ from a business perspective.”

“The more you know about your product the more difficult it is to position its true value. “

I have to disagree with Mr Mansour that these are true liabilities, in the sense that the absence of product knowledge doesn’t truly mitigate the liabilities. Good product management is fundamentally about good product management.

It’s your job as a good product manager to avoid running down the ratholes that you could run down as a result of your product knowledge.

Post by MTalbot at Seilevel Inc

check out other blogs here.

“So, what do you do for a living?”: A BA/Product Manager’s guide to surviving cocktail parties

Seilevel — Thu, 10 Jun 2010 13:52:00 GMT

By Jhulgan

I used to dread hearing the question, “So what do you do for a living?” This was often usually asked by a family member or other acquaintances not familiar with the software development lifecycle, IT, or business processes in general. For business analysts, product managers, and other software requirements types, it’s difficult to give an answer without being convoluted or sounding like Tom Smykowski:

This great post expresses a similar insight beautifully, but many of us struggle with good, one-sentence responses to what it is we do everyday in simple English. I thought I would plagiarize some ideas that I’ve heard from colleagues over the years and compile them here:

“We help businesses figure out what software they need to build to solve business problems.” This is a personal favorite of mine that I stole from Marc (who posts under mtalbot on this here blog). It’s especially relevant to IT consultants/contractors. Just about everyone knows what software is, and a lot of people understand that just about every business runs on some sort of software to solve business problems.
“We help communicate the business needs of a system in a language software developers understand.” A variation of this is, “We translate from business to geek”, although I am less fond of the second version because it veers into Smykowski land.
“We make sure the right software is being developed at the right time, for the right people.” The emphasis here is on the right software. This response is nice because it allows you to segue adeptly into a discussion about business objectives.
“We help the business get the most value out of their development dollar.” This response stresses the fact that you are not just a scribe or secretary writing things down, formatting them, and delivering them to the development staff. You are helping make the tough decisions on which features to cut and which bugs to fix, and quantifying those decisions in terms of dollars and cents.
“We work with the business to find the appropriate scope of a software development project and ensure that what is built is what the business expects.” Whenever I am asked the dreaded WDYDFAL question, this is what almost immediately comes to mind. Sometimes I fill in the details of working with pictures to help model current business processes (and desired business processes).

So how about all of our readers? What answers have you come up with? Do you dodge this question altogether, or do you sound like a fumbling Smykowski? Hopefully we can all help each other find good answers to this question. After all, you never know when you’ll be in a meeting with “The Bobs” and the pressure will be on!

You can check out our other blog posts here

BA Careers - Domain knowledge versus analysis skills

Miles Barker — Thu, 27 May 2010 12:44:00 GMT

I've been thinking a lot recently about the value of the BA, and BA recruitment - at all levels.

A common question that comes up is "Do I need to have experience in Industry X/Domain Y to work as a BA in that industry/domain?"

In a nutshell:

Is it like that now? Yes.
Should it be like that? Probably not.
Who can change it? Us - as BAs, managers and recruiters of BAs, and as candidates.

A lot of my thinking crystallised after a Thoughtworks breakfast meeting, about the challenges of modernising an infrastructure for selling train tickets (this is way more complex than you might think!) and seeing parallels with my work. Equally importantly, the CIO of the client co (David Jack of thetrainline.com) had a great track record of applying sound IT management in some very, very different industries.

Often, talking about "Industry X" is a slightly lazy shorthand for a bunch of more abstract things about challenges, approaches, and thinking.

I think some of the key determinants are the nature of a business or domain, e.g.

Is it B2C or B2B?
Is the process tightly constrained by market norms?
Does the "customer" (internal or external) directly interact with the system or business process you are working on, or with a service that is supported by it?
Are the system's users finite enough in number for a representative sample to be dealt with directly during the requirements process?
Are the users or Customers specialists themselves, or generalists/the general public?

and so on.

I know one BA who works (with great success) in the field of Adult Social Care:

B2C
Customer interacts with a service supported by his processes/systems
Customers/users can be sampled directly
Customers/users are specialists in their profession but generalists with regards to systems or process re-engineering.

So what his job is actually about is finding innovative ways (e.g. ethnography) to help professionals and their clients discover true requirements and create new processes to deliver those more effectively.

So I could tell you that "I'm a specialist in Securities Clearing and Settlement and Collateral Management". Or, I could tell you "I specialise in state-driven transactional processing, specifically in consolidating legacy processes and systems into service-oriented models that are sufficiently abstracted to support common processing regardless of product nuances or multiple B2B interface designs, in a time-constrained environment".

Now, which sounds more portable? And which tells you more fully what skills I have?

Of course, there ARE some cases where true domain expertise IS essential, typically those with some combination of highly specialised content AND time pressure AND stakeholders whose time is (genuinely) too valuable to spend "teaching" the BA. I'm reminded of pharma - the 2009 European BA Conference included a particularly memorable talk by Astra-Zeneca's Chris Marshall on the challenges of being BA in the blue-sky research space, where they are almost all ex-scientists themselves.

But most of the rest of the time, it's because things aren't documented or modelled, or aren't standardised, or aren't innovative.

I think we want to be more than just Subject Matter Experts with a BABOK veneer. Personally, I've learned the most and been most innovative when I've deliberately moved out of my comfort zone.

When we're in our comfort zone, we take a lot of what we know for granted
When we move out of our comfort zone, it's often easier to to get clarity without being bogged down in details

And we shouldn't forget, that if we just stick to the same domain and the same group of insiders, innovation will be much harder to come by. Banking sometimes feels like a merry-go-round with people coming in an implementing basically the same idea that they have at their last three employers. Which is fine if your aspirations extend no further than playing catch-up....

So what can we do about it?

1. Improve our in-house BA environment maturity, with properly modelled and documented domains, standard Use Case libraries, etc. so as to make the transition of non-specialist BAs easier.

2. As BA managers, open our eyes on recruitment based on skills and values, rather than knowledge, and phrase our job Specs accordingly

3. Build our BA teams focussed on ideas sharing and creativity

4. As BAs, revise our thinking and our CVs along the lines outlined above.

To be clear - I'm not saying that no-one in a team/project needs specialist knowledge - just that not everyone does - and that there are distinct advantages to mix and match teams and career mobility that we are currently (mostly) missing out on.

What do YOU think?

I will be leading a "BA Career Path and Qualifications" panel discussion on this and many other topics at the Business Analysis Conference Europe in London on 27-29 September 2010 - see http://www.irmuk.co.uk/ba2010/

Miles Barker

Professional Development Director of the UK Chapter of the IIBA

milesicbarker@gmail.com

Blurring the Lines between Business and IT

Derek Roos — Thu, 21 Jan 2010 10:51:00 GMT

A “What If” question for business analysts and IT professionals…

What if it suddenly became very easy for someone to do both your job and their own, at the same time? If history provides any forecast for the future of IT, we are likely to see some interesting changes in the way human capital is managed – especially for those of us involved in the emergence of cloud computing. Clouds push complexity to the background and allow users to focus on what really matters: functionality and costs.

Have you ever noticed how the education we receive often sets boundaries in our career aspirations? We are trained to do something, and do it well – but in doing so, we take for granted the fact that others are doing the same thing in a different field. Then, when we are faced with an inevitable change, we instinctively take a “That’s not what I’ve been trained to do, there are other people for that” mentality. Sure, there are the motivated few who push down boundaries and become renaissance men and women in their own right. But when everyone else is set in their ways, these people are often considered a risk… think: too many eggs in one basket.

Now, to regress from my pseudo-philosophical banter, this trend is becoming all the more apparent as business analysts become more involved in technical training. Most IT veterans would say that business analysts will never have the true know-how to implement their plans, requirements and recommendations. The modern business analyst usually considers themselves more of a problem solver than a programmer – hence the separation of labor in this function of any business. Having surveyed the blogosphere for opinions of business analysts and IT professionals, there seems to be a live (and even a bit emotional) discussion between those who say it is a natural, and therefore inevitable, progression and those who say it is a “pie in the sky” and that it will never happen.

Contrastingly, a growing population of believers has something to say about the segregation of business and IT. In a world of zeros and ones, the innumerable coding languages can only become more and more efficient. As coding languages are continuously created, survival of the fittest can account for the extinct languages of modern programming. An abstraction of these languages is an ongoing phenomenon with a light at the end of the tunnel. Some say that using abstract, visual and human-readable models instead of low-level code is a very important step towards commoditized coding.

I’ve come to think about this abstraction phenomenon as measure to increase efficiency. When our ancestors realized that making bricks was faster than packing sand, they were on to something similar. If someone else uses molds to make perfectly shaped bricks that can be built into any structure, the workers need different skills but can ultimately build more economically, the architect can plan more accurately, and the buyer can move in earlier. So, why deal with sand when we can get the bricks from vendors elsewhere. Why deal with code, when we can get software modules elsewhere? This, my friends, may be the future of today’s business analyst. In the future, what if business analysts had the skill set and the molds to create bricks that satisfy their requirements without the need to deal with code – or sand?

Derek Roos
CEO
www.mendix.com

How effective (or necessary) is a CBAP certificate for job searching?

Jason N — Tue, 15 Dec 2009 19:03:00 GMT

Hello Everyone!

I am new to this community blog, and I am interested in learning more about CBAP certification as it relates to my job search.

In brief, I was employed with a company for 14 years before being downsized in a mass complany layoff last year. Before the layoff, my title over my last 5 years was a Business Systems Analyst. I wrote and managed business/functional requirements, revised BRDs, did system testing, and served as a single point of contact between the client, end user, and IT teams.

In my job search, a lot of the BA positions that I've seen posted require experience in XML, HTML, or some other type of programming/coding experience I currently do not have.

That said, does anyone have any opinion of, direct experience, or comments about the Certified Business Analysis Professional (CBAP) certification program authorized through the International Institute of Business Analysis (IIBA)?

Any comments would be appreciated. Thanks

2009 Business Analyst Salary Survey Results

ASPE — Mon, 03 Aug 2009 14:34:00 GMT

Ravenflow and ASPE-SDLC have developed a specific, focused salary survey for the BA community. We shed light on the continued growth in need and value of business analysts and how they directly impact wages and opportunities. Thousands of our BA customers participated in the survey, and after third-party statistical analysis we present the results in this white paper (ASPE will also present an online seminar on the survey results). Learn a few surprises, and many valuable correlations across different demographic and educational data.

The white paper can be downloaded here http://www.aspetech.com/sdlc/offers/survey_offer_3.html

Exploring progressions into BA careers

Laura Brandenburg — Fri, 12 Jun 2009 21:58:00 GMT

I know. You recently read Adrian’s latest post and said: “Yes! that’s exactly what I’m looking for! I want an employer to hire me, mentor me as a new business analyst, and then let me blossom in this career.” I wholeheartedly agree with Adrian—as business analysts we need to be mentors for other potential business analysts. I was lucky enough to become a business analyst after a year and a half as a QA engineer. I worked for the first 3 months under the wing of a senior BA and then was set loose on the biggest software project the company had started to-date. I guess they trusted me.

I wish I could say these sorts of opportunities abound but the fact is they don’t. I was lucky. I was in a growing organization that supported professional development. But I was also career-minded, consistently discontent, and always looking to improve something somewhere. I was not a “tell me what to do and I’ll do it employee”, I was a “why can’t I do that?” employee. I faced barriers, but eventually I managed to earn the responsibilities I wanted and work my way a bit up the career ladder.

In recent months, I’ve had the opportunity to hear the stories of many business analysts about how they started their business analyst careers. The stories varied but had a common theme: one step at a time. Career progressions often involved incorporating some business analyst responsibilities into their day-to-day role. Some became “BAs” without a real knowledge of what that meant or that a profession existed. Others were more like me and took a flying leap but often within the same company and with a network of support. A few managed to transition careers and companies in the same job change by selling their "BA" experiences. Darn impressive.

Regretfully, I’m not in a position to hire you, but I am looking to help on the mentoring front, starting with publishing a “how to” guide based on what I’ve learned from people who’ve successfully made the transition in this environment. We are a profession that favors experience. It can be tricky to accumulate but with a little persistance and some proper guidance you can break into this profession. Take a sneak peak to learn a bit more about How to Start a Business Analyst Career and leave your email for a special discount when the book is published in the next month.

About the author:

Laura Brandau is an independent business analyst consultant and hosts Bridging the Gap between Business and IT, a blog for business analysts about solving business problems.

Raising the bar in Business Analysis and Internal Consulting

SmartProjects — Tue, 10 Mar 2009 04:55:00 GMT

Internal Business Analysis and Consulting teams are increasingly recognised as playing a vital role in delivering successful projects. More and more they are contributing to complex and strategic projects and performance expectations from executives are getting higher.

Are you interested in improving Business Analysis and Internal Consulting capability in your organisation?

I would like to share with you a new released video about "Raising the bar in Business Analysis and Internal Consulting".
It offers suggestion on what you can do to better prepare and develop your team and outlines a four-step approach to assessing and baselining your team's capability.

Top Ten Signs that Business Analysis is a Career Choice for you.

Laura Brandenburg — Sun, 18 Jan 2009 20:58:00 GMT

So you are interested in becoming a business analyst or maybe you’ve just always thought it would be fun to get more involved in technology projects. If you are on the business side, but are thinking of a technology role, here are some signs you should give business analysis more than a fleeting glance:

1) You find yourself in meetings and like it. You always seem to sense when people are talking at each other but not communicating with each other. Bonus points if you find yourself in the middle of these conversations because you feel compelled to make them understand each other.

2) You like to write, especially a precise type of writing, and you are comfortable working independently at your computer for 2-3 hours at a time.

3) You always seem to find something wrong with a website or piece of software and ask yourself, why didn’t they think to handle that better? (Note: this attribute also makes for a good tester, but great BAs build quality into the requirements by asking these sorts of questions.)

4) You can handle tense situations but you don’t feel the need to be in the conflict. Helping people wade through different opinions and make informed decisions is one of the most important things a BA does.

5) You like to draw on the white board. Really, this is absolutely necessary. As a BA, you need to engage your stakeholders and nothing does this like a few scribbles on the wall or a napkin.

6) You are a bit of a preservationist. The idea of reading through meeting notes from 6 months ago might not take you into the upper orbs, but it does get you a wee bit excited, especially when you find the precise bullet point that reminds everyone why you threw that idea out last time, saving an hour of repetitive discussion.

7) Your co-workers come to you with questions about the legacy system you work with day-to-day. You understand not just how to use the system to do your job, but why things work the way they do. You wonder why everyone else just doesn’t get it.

8) You like to ask questions. You make sure you really know what someone meant when they said what they said.

9) You typically understand what the techies are saying. There are exceptions to this rule because there are exceptional techies that even the best of us struggle to interpret. But, all in all, you can figure out what they mean and, most importantly, the implications of what they mean to the business.

10) You naturally clarify problems before getting to solutions. You might annoy people with all your questions about what the problem “really” is and why they think it’s something it’s not. But you also rarely get caught with your pants down expending lots of effort to solve a problem only to find out no one cares about the solution. And when you do, you only blame yourself.

Bonus Point: You are solutions-oriented. Some purists among my class might argue with me here because the focus of the BA role is to determine “what” needs to be done not “how” it needs to be done. But in my experience, the best BAs collaborate with every member of the team every step of the way and actively participate in solving the problem and, especially, selecting the best solution from a collection of possible ones. A perfect problem that can’t be solved or can’t be solved with the resources you have is, well, just a problem. And that annoys everyone.

Post submitted by: Laura Brandau of Clear Spring Business Analysis who shares her thoughts on the business analysis profession in her blog: Bridging the Gap between Business and IT.

Software project methodologies

Craig Brown — Sun, 18 Jan 2009 09:26:00 GMT

Jurgen Appelo runs a blog at Noop.nl. He posted a summary on some project methods. I migrated them into a ppt for slideshare.

I hope this is intereting for you.

Software Project Methods

The 6th best job in America

Craig Brown — Fri, 09 Jan 2009 12:10:00 GMT

The Best Jobs in America

Analyst ranks high in "A Comprehensive Ranking of 200 Different Jobs"

Adrian M. — Thu, 08 Jan 2009 20:21:00 GMT

JobsRated.com released the results of a study they did of 200 jobs and how they rank based on a number of factors such as:

Environment
Income
Outlook
Physical Demands
Stress

Systems Analysts was in the top 10 which looks like this:

Mathematician
Actuary
Statistician
Biologist
Software Engineer
Computer Systems Analyst
Historian
Sociologist
Industrial Designer
Accountant

So - just another piece of good news for the Business Analysts and Systems Analysts out there.

Memories of IT

David Wright — Fri, 20 Jun 2008 02:50:00 GMT

I am now lucky enough to be working at a consulting company with a great group of experienced people, and we do share some great "war stories", and it made me think that I do have my share of experiences that, if written down, some small number of people may find interesting. Seems to me a blog is great for that.

I would call this memories rather than a "memoir"; the latter would imply I have spent time researching myself and might, for example, be able to name all the people I went to school with or have worked with over the last 3 decades; not gonna happen. People who write Memoirs were also usually prescient enough to keep a diary or journal since a young age, but not I.

But, I don't think anybody will be checking my facts or lack of them; and as a blog, any reader of a certain age who wants to chime in is most welcome.

Where does it start? Spring 1972, 10th Grade ( or "Grade 10" as we called it in Canada), looking at optional courses for 11th grade in the fall, and my eyes come upon "Computer Science"; sounds interesting, what the heck...

Next time: Highschool computer science...

Cascade - The Book

David Wright — Thu, 08 May 2008 02:55:00 GMT

This blog has been started because, like anyone who writes a bit for a living, I thought I had a book to write...so I did.

This blog also hi-lights the arrival of lulu.com, a website that will publish your book with the 'tarnish' of a vanity presss.

So, check both out at http://www.lulu.com/content/2088656 . The book is "Cascade - Better practices for effective delivery of information systems in a multi-project environment. "

Future posts will feature selections from the book, starting with the forward/introduction, so come back tomorrow!

David Wright

Business Analysts Needed - Everywhere!

Craig Brown — Wed, 13 Feb 2008 18:42:00 GMT

A new survey highlights the importance of proper requirements management

“More than half "did not have professional, trained staff dedicated to the function of getting requirements, and the vast majority view the process of getting requirements to be inefficient," the report states.

Read the original article here.

Key points I got from the article;

Companies still aren’t paying attention to requirements management.

Come on people, if you don’t stop and think about what you want to get out of this project, of course you are going to go over budget and beyond the schedule.

Non-IT people managing requirements doesn’t work, but neither does having IT people management requirements.

In both cases the wrong people are managing the requirements. The article goes on to say that a business-IT joint effort gives better results, but still not good enough. What is really needed is trained and experienced business analysts, who’s profession is managing requirements.

The rate of project failure is still huge.

The article gave a definition of failure that included very late, way over budget and with a significant portion of the requirements missing. I really did think we were doing better as an industry these days.

BA Fad?

sherlockmh — Tue, 13 Nov 2007 18:09:00 GMT

Is this the start of a new trend, or a short-term blip?

Recruiters are calling, and making "extra" visits to IIBA and other meetings. They say they have more corporate demand for Business Analysts, than they can fill.

Many programming jobs have moved to India and other locations. Now there are not enough people left to supply the "glue in the middle" - eliciting, finalizing, documenting and managing business requirements, through the design and implementation process.

Some programmers with a "mixed" background (BA and Programmer, not to mention other "Systems Analysis" work) are making the switch: moving to a job title that is less likely to be cut in the next round of layoffs and outsourcing.